Willkommen zu allesnurgecloud.com – Ausgabe #232
Während die Presse sich entweder mit der Straße von Hormuz oder mit der Rettung von Timmy beschäftigt, ist in der Cloud Welt wieder einiges passiert und ich hab ein paar Themen dieser Ausgabe schon wieder für die nächste Woche verschoben.
Falls du Themen hast und über interessante Links stolperst, schick mir dir gerne einfach als Antwort auf den Newsletter – Danke!
Neben dem ganzen Datacenter Hype in den USA gibt es auch Bundesstaaten wie Maine, die nun ein Verbot für DCs mit mehr als 20MW Strombedarf erwirken wollen. Das Gesetz ist im Ober- und Unterhaus schon beschlossen, nur die Gouverneurin muss noch unterschreiben.
Für das Online-Magazin von it-daily habe ich einen Gastartikel zum Thema „Cloud Exit oder Cloud Umzug“ geschrieben, der verschiedene Aspekte eines „Hyperscaler Exits“ beleuchtet und einordnet. Schreib mir genre, wie du ihn findest. Passend dazu findest du mich am Dienstag & Mittwoch auf der Rack & Stack Konferenz von Golem – hier halten Eugen und ich den Vortrag „Mut zum Cloud Exit“, der das gleiche Thema mit einem Praxisbeispiel vorstellt. Schreib mir gerne, falls wir uns dort sehen.
So, und nun viel Spaß mit Ausgabe #232.
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 168 habe ich mit Jannik Lindner gesprochen. Jannik hatte jahrelang eine Affiliate-Firma aufgebaut und das verdiente Geld in eine Meeting Software investiert – ohne je eine Subscription zu verkaufen. Heute baut er mit seinen Co-Foundern von Früher an rawshot.ai – mit Rawshot kannst du KI-Produktfotos für deine Fashion-Brand und Online-Shop generieren. Dazu baut er mit careertrainer.ai ein audio basiertes KI-Rollenspiel-Training für Führungskräfte und Vertriebsmitarbeitende. Gerne kannst du die Folge auf YouTube schauen oder wie immer bei Spotify, Apple und allen anderen Playern anhören.
Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:
EU vergibt 180 Mio für souveräne Cloud
Die EU-Kommission hat am Donnerstag ihre Ausschreibung über 180 Millionen Euro für souveräne Cloud-Dienste vergeben – das Ergebnis liest sich wie ein Who-is-who der europäischen Cloud-Hoffnungen. Den Zuschlag bekamen Post Telecom aus Luxemburg mit CleverCloud und OVHcloud, die deutsche STACKIT (Schwarz Digits), das französische Scaleway sowie ein Konsortium rund um Proximus aus Belgien mit dem Thales-Google-Joint-Venture S3NS, Clarence und Mistral. Der Rahmenvertrag läuft über sechs Jahre auf Basis des neuen Cloud Sovereignty Framework, das Heise bereits im Oktober 2025 eingeordnet hatte.
Das Framework definiert acht Souveränitäts-Ziele und sogenannte SEAL-Level von 0 bis 4:
- SEAL-2 – Daten-Souveränität nach EU-Recht, Mindestniveau für die Ausschreibung (Proximus-Konsortium)
- SEAL-3 – Lieferkette immun gegen Störungen durch Nicht-EU-Dritte (Post Telecom, STACKIT, Scaleway)
- SEAL-4 – komplett europäische Lieferkette vom Chip bis zur Software, bisher von niemandem erreicht
Politisch brisant: Die Kommission bestätigt erstmals, dass nicht-europäische Technologie unter strenger Governance als souverän gelten kann – ein Zugeständnis, das Scaleway oder OVH kaum begeistern dürfte. Insight EU Monitoring hat nachgezählt, dass OVHcloud und Google-nahe Akteure die mit Abstand meisten Meetings mit dem zuständigen Kabinett hatten – ein Schelm, wer Böses denkt.
180 Millionen über sechs Jahre sind eher Symbolpolitik als Marktkorrektur – AWS investiert allein in Brandenburg 7,8 Milliarden in seine „Sovereign Cloud“. Der eigentliche Hebel wird der Cloud and AI Development Act (CADA) sein, bereits zwei Mal verschoben und nun erwartet für Mai 2026. Passend dazu Ausgabe 179 zum US-Ausstieg und Ausgabe 191 zur deutsch-französischen KI-Allianz.
Commission awards €180 million tender for sovereign cloud to four European providers
Project Houdini: AWS baut Datacenter wie Lego
Amazon versucht die Bauzeit seiner Rechenzentren drastisch zu verkürzen – und greift dafür auf ein altbekanntes Rezept zurück: Vorfertigung im Werk. Eugene Kim hat bei Business Insider interne Dokumente zu Project Houdini ausgewertet, benannt nach dem Entfesselungskünstler – der Name ist Programm, denn AWS will sich aus den Fesseln der Baustellen-Logistik befreien.
Der Plan: Statt Serverräume komplett vor Ort zu errichten, werden sogenannte Skids in Fabriken vorgefertigt – etwa 45 Fuß lange, rund 9.000 Kilogramm schwere Module mit bereits installierten Racks, Stromverteilung, Verkabelung und Brandschutz. Die Kennzahlen aus den internen Dokumenten:
- Bauzeit bis zur Server-Installation sinkt von 15 Wochen auf 2–3 Wochen
- Einsparung von bis zu 50.000 Elektriker-Stunden pro Anlage
- Bisher 60.000 bis 80.000 Arbeitsstunden für ein Data Hall
- Ziel: über 100 Datacenter pro Jahr in der Pipeline
AWS arbeitet mit Cupertino Electric zusammen, erste Produktionsstandorte entstehen in Topeka, Houston und Salt Lake City. Ab August soll der Ansatz einsatzbereit sein. Der Kontext: Amazon plant dieses Jahr 200 Milliarden Dollar Capex, Andy Jassy sprach im Aktionärsbrief von anhaltenden Kapazitätsengpässen – passend zum Hyperscaler-Wettlauf aus Ausgabe 175.
Wirklich neu ist das Konzept nicht – Schneider Electric und Vertiv bauen seit Jahren modulare Lösungen, Crusoe fokussiert auf AI-Workloads. Neu ist die Tiefe der Integration und der Maßstab. Den eigentlichen Engpass löst Houdini allerdings nicht: Dimitrios Nikolopoulos von Virginia Tech erinnert daran, dass Netzanschlüsse und Umspannwerke Jahre brauchen. Wenn der Stromanschluss fehlt, hilft auch das schnellste Modul-Deployment nichts.
Amazon creates ‚Project Houdini‘ to make data center delays disappear
Anzeige
Hier könnte Deine Werbung stehen
Mach es wie Checkly, ilert, anny, Schutzwerk oder Superluminar und bewirb dein Stellengesuch, deine Dienstleistung oder dein SaaS-Tool bei allesnurgecloud. Beispiele der bisherigen Schaltungen findest du direkt hier.
Der allesnurgecloud-Newsletter erreicht über 2.000 Leser per E-Mail und RSS – mit einer Öffnungsrate von über 65 %. Wöchentlich, mit Themen rund um Cloud, Infrastruktur und Open Source.
Sponsoring ab 200 € pro Ausgabe (Einzelbuchung). Du möchtest Sponsor werden? Schreib mir gerne – alle Infos zur Zusammenarbeit auf Anfrage.
Cal.com: Vom Open-Source-Poster zum Closed Source
Bailey Pumfleet, Gründer von Cal.com, hat auf dem Cal.com-Blog eine für die OpenSource-Community unangenehme Nachricht verkündet: Nach fünf Jahren als „Open Source Champion“ wechselt die Calendly-Alternative auf closed source. Die Begründung klingt zunächst nachvollziehbar, bei genauerem Hinsehen aber reichlich konstruiert.
Pumfleets Argumentation: KI-gestützte Security-Tools könnten öffentliche Codebases inzwischen systematisch nach Schwachstellen abscannen. Als Beleg nennt er einen Fall, in dem eine KI eine 27 Jahre alte Lücke im BSD-Kernel gefunden und innerhalb weniger Stunden einen funktionierenden Exploit erzeugt habe. Open Source sei damit vergleichbar mit „den Bauplänen des Tresors“. Die Gegenthese – dass mehr Augen auf den Code eben auch mehr Sicherheit bedeuten (Linus’s Law) – kommt im Beitrag nicht vor.
Prompt gekontert hat Alex Schapiro von Strix, selbst Betreiber einer Open-Source-Plattform für autonome AI-Security-Agents mit 24.000 GitHub-Stars. Interessantes Detail am Rande: Strix hatte Cal.com in den vergangenen Wochen bereits im Rahmen einer Responsible Disclosure Schwachstellen gemeldet. Schapiros Argument: Moderne AI-Agenten arbeiten ohnehin black-box – sie probieren APIs, Browser-States und Webhooks live durch, unabhängig vom Repo-Zugriff. „Security through obscurity“ sei gegen automatisierte Angriffe eine exponentiell schlechtere Wette als gegen menschliche Angreifer. Seine Alternative: AI-Verteidiger in die CI/CD-Pipeline integrieren, statt den Code zu verstecken.
Cal.com hatte ich zuletzt in Ausgabe 60 als Paradebeispiel für funktionierende OpenSource-Geschäftsmodelle vorgestellt – damals gab es 25 Millionen Dollar Funding und man warb offensiv mit radikaler Transparenz unter cal.com/open. Was übrig bleibt:
- Produktions-Codebase wandert ins private Repository
- Der öffentliche Fork heißt künftig Cal.diy, bleibt unter MIT-Lizenz
- Auth und Datenhandling wurden im Closed-Source-Zweig bereits „massiv umgeschrieben“
- Cal.diy ist explizit für Hobbyisten gedacht – nicht für Produktionseinsatz
Der Timing-Verdacht liegt nahe: Ein VC-finanziertes Startup mit inzwischen mehreren Runden muss irgendwann Enterprise-Kunden monetarisieren, und die wollen keine Self-Hosting-Konkurrenz zum eigenen SaaS-Angebot. Die Sicherheits-Begründung wirkt wie ein PR-geeigneter Mantel für eine klassische Kommerzialisierungsentscheidung.
Mal schauen, wie sich das Projekt weiterentwickelt – nutze es selbst nach wie vor viel lieber als andere Tools zur Terminabstimmung für Podcast, Firma und Co. Aber vielleicht doch mal ein paar Alternativen checken.
Cal.com is going closed source. Here’s why.
Mythos Preview schließt 32-stufigen Netzwerkangriff ab
Als Ergänzung zu Anthropics eigenem Glasswing-Bericht der letzten Ausgabe hat das britische AI Security Institute (AISI) nun seine eigene unabhängige Evaluation von Claude Mythos Preview veröffentlicht. Bemerkenswert: Das AISI beobachtet die KI-Cyberfähigkeiten bereits seit 2023 und hat seine Evaluierungs-Infrastruktur in dieser Zeit schrittweise von einfachen Chat-Probes über CTF-Challenges bis hin zu komplexen Mehrstufen-Angriffsimulationen ausgebaut – ein methodisch belastbarer Vergleichsrahmen.
Auf Expert-Level CTF-Aufgaben – die vor April 2025 kein Modell lösen konnte – kommt Mythos Preview auf 73 % Erfolgsrate. Wichtiger ist das Ergebnis auf „The Last Ones“ (TLO), einer eigens entwickelten 32-stufigen simulierten Unternehmens-Netzwerkangriff-Simulation, die menschliche Experten rund 20 Stunden kostet. Mythos Preview schloss sie in 3 von 10 Versuchen vollständig ab und absolvierte im Schnitt 22 der 32 Schritte. Kein anderes getestetes Modell hat TLO bisher vollständig durchlaufen; Opus 4.6 kommt auf durchschnittlich 16 Schritte.
Das AISI benennt die zentrale Einschränkung dabei selbst: Die Testumgebungen enthalten weder aktive Defender noch Endpoint Detection, und das Modell trägt keine Konsequenzen für Aktionen, die in echten Systemen Alarme auslösen würden. Ob Mythos Preview auch gut abgesicherte Produktivumgebungen kompromittieren kann, bleibt damit offen. Die unabhängige Evaluation durch eine staatliche Stelle macht Anthropics eigene Red-Team-Zahlen dennoch deutlich belastbarer – und das AISI kündigt bereits härtere Testumgebungen mit aktiven Verteidigern für zukünftige Evaluierungen an.
Our evaluation of Claude Mythos Preview’s cyber capabilities
LaLiga gegen Cloudflare: Kollateralschaden-Internet
Eine Stunde Debugging für einen simplen docker pull – weil in Spanien gerade Fußball läuft. User littlecranky67 schilderte auf Hacker News, wie sein lokaler GitLab-Runner mit kryptischen TLS-Fehlern abbrach, bis er im Browser die Meldung sah: Zugriff auf diese IP per gerichtlichem Beschluss geblockt, verhängt auf Antrag der Liga Nacional de Fútbol Profesional und Telefónica, wirksam nur während der Spielzeiten. Der Post sammelte über 1.146 Upvotes – in der Tech-Community ist das Thema längst Routine-Frust.
Die Dimension ist größer, als der Einzelfall vermuten lässt. Spanische ISPs blockieren während der LaLiga-Spiele nicht nur Cloudflare, sondern auch Fastly, Akamai, BunnyCDN, Alibaba und CDN77 – auf IP-Ebene, nicht per DNS. Kollateralschäden aus dem Thread:
- Eine Frau konnte ihren demenzkranken Vater während eines Spiels nicht per GPS-Tracker orten, weil dessen Backend auf Cloudflare läuft
- Smart-Home-Alarme und automatische Türen fallen regelmäßig aus
- Firmen verlieren Umsatz, weil Produktivsysteme und CI-Pipelines stehen
LaLiga argumentiert mit dem Schutz vor Piraterie der Live-Streams. Das Absurde: Die Piraten umgehen die Sperren längst per VPN, wie ein Kommentator im Thread notiert – sein Nachbar schaue die Piraten-Streams problemlos, während er selbst nicht deployen könne. Cloudflare weigert sich zu Recht, ohne Gerichtsbeschluss präventiv Kundenkonfigurationen zu blockieren. Die spanische Justiz erlaubt LaLiga stattdessen das pauschale Blocken ganzer IP-Bereiche – ohne Prüfung, ohne Kollateralschaden-Abwägung.
Nachdem Cloudflare sich im Online-Casino-Fall aus Ausgabe 147 als streitbarer Partner erwiesen hat, zeigt sich hier eine andere Seite: Diesmal ist Cloudflare nicht Täter, sondern Kollateralschaden einer politisch-kommerziellen Verstrickung. Fastly hat die LaLiga-Forderungen übrigens akzeptiert und detektiert illegale Streams inzwischen in Echtzeit – ein gefährlicher Präzedenzfall für die Infrastruktur-Neutralität im Netz. Dass die nächste VPN-Sperre bereits gerichtlich angeordnet wurde, zeigt die Eskalationsrichtung.
Tell HN: Docker pull fails in Spain due to football Cloudflare block
30 WordPress-Plugins: Backdoor nach Verkaufs-Deal
Eine Woche nach dem Widget-Logic-Angriff ist es wieder passiert – diesmal in deutlich größerem Maßstab. Austin Ginder von Anchor Hosting hat in einem detaillierten Forensik-Bericht dokumentiert, wie ein unbekannter Käufer namens „Kris“ über die Plattform Flippa das Portfolio von Essential Plugin für einen sechsstelligen Betrag übernommen und in 30+ WordPress-Plugins eine Backdoor eingebaut hat. Betroffen sind populäre Plugins wie Countdown Timer Ultimate, Hero Banner Ultimate und Popup Anything on Click mit jeweils zehntausenden Installationen.
Die Technik ist bemerkenswert sauber umgesetzt:
- Backdoor wurde im August 2025 platziert und schlief 8 Monate dormant
- Ein Commit mit dem harmlosen Changelog „Check compatibility with WordPress version 6.8.2″ fügte 191 Zeilen Code mit PHP-Deserialization-RCE ein
- Aktivierung am 6. April 2026 durch SEO-Spam-Injection in
wp-config.php - C2-Domain wurde über Ethereum Smart Contracts aufgelöst – klassische Domain-Takedowns sind damit wirkungslos
- Spam wurde nur an Googlebot ausgeliefert, für Seitenbetreiber unsichtbar
Der Originalautor, ein indisches Team rund um Minesh Shah, hatte sein Business Ende 2024 bei sinkenden Umsätzen auf Flippa gelistet. Flippa hat über den Deal sogar noch eine Case Study veröffentlicht. WordPress.org schloss am 7. April alle 31 Plugins an einem Tag, ein Force-Update auf Version 2.6.9.1 deaktivierte den Phone-Home-Mechanismus – aber nicht den in wp-config.php injizierten Code. Seitenbetreiber müssen hier selbst nachschauen.
Das Muster erinnert stark an die XZ-Utils-Backdoor aus Ausgabe 141: langsam aufgebautes Vertrauen, dann ein platzierter Payload, der monatelang schläft. WordPress.org hat weiterhin kein Mechanismus für Ownership-Transfers im Plugin-Directory – keine Benachrichtigung an Nutzer, kein zusätzliches Code-Review bei neuen Committern. Genau diese Lücke machen sich Angreifer seit Jahren zunutze, bereits 2017 gab es mit dem Display-Widgets-Plugin einen vergleichbaren Fall.
Someone Bought 30 WordPress Plugins and Planted a Backdoor in All of Them.
zerobrew, nanobrew: Schnelle Homebrew-Clients – aber dank wessen Arbeit?
Andrew Nesbitt beschreibt auf seinem Blog treffend, was hinter den aktuellen Homebrew-Alternativen steckt. zerobrew (Rust, „uv-style architecture“) und nanobrew (Zig, 1,2 MB statisches Binary) werben mit 4,4× bzw. bis zu 500× Speedup gegenüber Homebrew – verschweigen dabei aber, dass sie gegen homebrew-core auflösen, Bottles herunterladen, die Homebrews CI gebaut hat und Homebrews Bandbreite bezahlt, und Cask-Definitionen parsen, die Homebrew-Contributor pflegen. Sie sind alternative Clients für ein fremdes Registry.
Die Benchmark-Zahl, die beide feiern – Warm-Cache-Reinstall – misst, wie schnell man ein clonefile aus einem Content-Addressable-Store machen kann. Nützlich zu optimieren, aber kaum relevant für den typischen Use-Case: neuer Laptop, Tool, das man noch nicht hat. Die Cold-Cache-Zahlen liegen deutlich näher beieinander, weil dann alle auf dasselbe CDN warten.
Den eigentlichen Kern formuliert Nesbitt so: Der Flaschenhals ist nicht Ruby vs. Rust oder Zig, sondern das Fehlen eines stabilen deklarativen Paketschemas. Homebrew hat das bereits für den Bottle-Pfad gelöst – mit der formula.json-API, die erst beide Tools möglich macht. Die langsamen Teile von Homebrew – Ruby DSL-Auswertung, post_install-Hooks, der Long Tail komplexer Formulae – sind genau die Teile, die beide als „out of scope“ erklären. Auf HN fasste ein Kommentar das so zusammen: „There’s a new vibe coded Homebrew frontend with partial compatibility and improved speed every few weeks.“
Standing on the shoulders of Homebrew
Vibe Coded Helm Charts & self-hosting funktionieren nicht?
Im Replicated-Blog greift Kaylee McHugh ein Thema auf, das in der aktuellen KI-Euphorie leicht übersehen wird: Vibe Coding – also das promptgetriebene Generieren von Code ohne tiefes Verständnis – funktioniert für Prototypen, versagt aber bei Self-Hosted-Software auf ganzer Linie.
Das Argument ist einfach und treffend: Ein KI-generiertes Helm-Chart installiert sich vielleicht problemlos in einer sauberen Testumgebung. Aber echte Kundenumgebungen sind das genaue Gegenteil davon – air-gapped, mit strikten RBAC-Policies, älteren Kubernetes-Versionen oder Netzwerkkonfigurationen, die stillschweigende Annahmen brechen. Der erste helm install klappt; was danach kommt – Upgrades, Rollbacks, Statemigrationen, Debugging ohne direkten Zugriff – ist ein anderes Problem.
McHugh benennt das strukturelle Muster dahinter: Self-Hosted-Software altert schlecht, wenn sie nicht von Anfang an dafür gebaut wird. Kleine Entscheidungen beim Deployment kumulieren sich. Ein zu permissives RBAC wird zum Sicherheitsrisiko. Eine fehlende Migrationspfad-Logik korrumpiert nach sechs Monaten Produktionsdaten. Und das alles lässt sich nicht durch bessere Prompts lösen – es erfordert ein Verständnis davon, wie Systeme über Zeit evolvieren.
Der Artikel ist natürlich auch Werbung für Replicated, eine Plattform für genau dieses Problem. Das schmälert die Beobachtung aber nicht. Wer gerade darüber nachdenkt, sein SaaS-Produkt als Self-Hosted-Variante anzubieten, sollte sich die Fragen von Day-2 Operations stellen, bevor der erste Kunde fragt, warum das Upgrade seinen Cluster lahmlegt oder die Daten der Elasticsearch Instanz public sind. Naja, das ist mit Menschen ja auch schon hier und da passiert.
You Wouldn’t Vibe Code a Skyscraper. Don’t Do It for Self-Hosted Software
Datencenter im Weltall – Spinnerei oder nächste Logik?
Philip Johnston, Co-Gründer von Star Cloud, argumentiert im 632nm-Podcast, dass das eigentliche Limit des KI-Skalierens nicht Chips oder Algorithmen sind, sondern Energie und Infrastruktur. Neue Kraftwerksprojekte auf der Erde brauchen Jahre an Genehmigungsverfahren, Flächenkonflikten und regulatorischen Hürden – genau dann, wenn die Nachfrage exponentiell wächst.
Der Kernangriff: Ein Quadratmeter Solarmodul im Orbit produziert achtmal so viel Energie wie auf der Erde – kontinuierlich, ohne atmosphärische Verluste, ohne Nacht. Kühlung wird trivial, weil Wärme einfach ins Vakuum abgestrahlt wird. Datacenter-Kosten teilen sich grob in Chips, Infrastruktur und Energie auf – die Chips bleiben gleich, egal wo. Infrastruktur und Energiekosten lassen sich im Orbit hingegen massiv reduzieren.
Der Haken ist der Launchwert. Johnston rechnet den Break-even bei $500/kg in den Orbit. Noch sind die Kosten zu hoch – aber die Entwicklung vollständig wiederverwendbarer Raketen verändert diese Gleichung schnell. Star Cloud hat bereits einen Satelliten mit handelsüblichen GPUs gestartet, um den Betrieb von Compute im Orbit zu validieren. Thermomanagement und Leistungsdichte bleiben die offenen Ingenieursaufgaben.
Das Thema ist nicht neu für den Newsletter: In Ausgabe 156 hatte ich bereits Lumen Orbit vorgestellt – ein YC-Startup mit demselben Grundansatz, das den Case mit einem 40-MW-Cluster durchrechnete: $8,2 Millionen Betriebskosten über 10 Jahre im Weltall versus $167 Millionen auf der Erde. Star Cloud und Lumen Orbit zeigen, dass sich mittlerweile mehrere Teams unabhängig voneinander mit demselben Kernargument ernsthaft beschäftigen – „If it’s cheaper to do it in space, we’ll be doing it in space.“
Ich weiß ja nicht, bin da eher skeptisch, aber vielleicht funktioniert das ja irgendwann vernünftig genug, dass man dort dann „Modell Training“ oder so latenzunabhängig machen kann?
Schmunzelecke
Ok, nun wird es wild – unter Windows kannst du dank OpenGL Doom über DNS spielen. Die ganze Doom Shareware ist dabei in 1.964 DNS TXT Records komprimiert abgelegt und das PowerShell Script aus dem Repo spielt das WAD File dann aus diesen Records ab.
In San Diego haben sich ein paar Remote Worker am Strand zu „Remote Work“ getroffen (Video bei Instagram).
💡 Link Tipps aus der Open Source Welt
Onyx – Open Source AI Plattform mit RAG, Agents und Deep Research
Onyx ist eine Self-Hosted AI-Plattform, die LLMs mit RAG, Web Search, Code Execution, Deep Research und über 50 Konnektoren zu einer vollständigen Anwendungsschicht verbindet. Deployment per Einzeiler: curl -fsSL https://onyx.app/install_onyx.sh | bash.
Key Features:
- Agentic RAG: Hybrid-Index (Vektor + Keyword) mit AI Agents für Information Retrieval aus eigenen Datenquellen
- Deep Research: Mehrstufiger Research-Flow für ausführliche Reports – laut eigenen Angaben top im Leaderboard (Stand Feb 2026)
- Custom Agents: Eigene Agents mit individuellen Instruktionen, Wissensquellen und Actions bauen
- Web Search, Code Execution, Image Generation, Voice Mode, Artifacts – alles integriert
- 50+ Konnektoren: Indexbasiertes Anbinden von Datenquellen oder via MCP
- LLM-agnostisch: Alle großen Provider (Anthropic, OpenAI, Gemini) und Self-Hosted (Ollama, vLLM, LiteLLM)
Enterprise Features: SSO (Google OAuth, OIDC, SAML), RBAC, Analytics, Query History, Whitelabeling, SCIM User Provisioning, PII-Filterung.
Zwei Modi: Lite (Chat UI + Agents, unter 1GB RAM) und Standard (voller Stack mit Vektor-Index, Background Workers, Redis, MinIO).
Tech Stack: Python (64%), TypeScript (30%). Deployment via Docker, Kubernetes oder Helm/Terraform.
Onyx positioniert sich als das „alles in einem“-Paket für Teams, die eine eigene AI-Plattform betreiben wollen – vergleichbar mit einer self-hosted Alternative zu ChatGPT Enterprise mit RAG. Die Breite der Features ist beeindruckend, der Lite-Modus senkt die Einstiegshürde. Für Teams, die RAG über interne Datenquellen brauchen und nicht auf Cloud-Anbieter setzen wollen, aktuell eine der vollständigsten Open-Source-Optionen.
https://github.com/onyx-dot-app/onyx
Miasma – Poison Pit für AI Web Scraper
Miasma ist ein leichtgewichtiger Server, der AI-Crawler in eine Endlosschleife aus vergifteten Trainingsdaten lockt. Versteckte Links auf der eigenen Website leiten Scraper zu Miasma, das ihnen poisoned Data zusammen mit selbstreferenziellen Links serviert – ein endloses Buffet aus Datenmüll für die Slop-Maschinen.
Key Features:
- Honeypot-Prinzip: Versteckte Links (unsichtbar für Menschen, sichtbar für Crawler) leiten Scraper zu Miasma, das sie in einer Endlosschleife aus generierten Seiten gefangen hält
- Poisoned Training Data: Jede Seite enthält vergiftete Inhalte plus konfigurierbare Anzahl selbstreferenzieller Links – Scraper graben sich immer tiefer
- Konfigurierbare Tiefe: Per
--max-depthund--link-countfestlegen, wie viele Seiten ein Scraper konsumiert, bevor er losgelassen wird (~250MB Poison pro Scraper bei Standardkonfiguration) - Minimaler Footprint: In Rust geschrieben, ~1MB RAM pro Verbindung, Force-Gzip-Option zur Reduktion von Egress-Kosten
- Einfache Integration: Hinter Nginx/Reverse Proxy, mit Rate Limiting und robots.txt-Schutz für legitime Bots
Setup: Versteckte Links im HTML platzieren, Nginx-Location konfigurieren, miasma --link-prefix '/naughty-bots' starten. Ein kreatives Werkzeug für Website-Betreiber, die sich gegen aggressives AI-Scraping wehren wollen. Technisch sauber umgesetzt – schnell, konfigurierbar und ressourcenschonend. Wichtig: robots.txt für legitime Suchmaschinen pflegen und die Disclaimer ernst nehmen – das Deployment birgt Risiken. Für alle, die nicht einfach nur blockieren, sondern aktiv zurückschlagen wollen.