Willkommen zu allesnurgecloud.com – Ausgabe #245
Bei HackerNews ging „What AI did to stackoverflow in a graph“ etwas viral – kein Wunder, wenn man sich die Auswirkungen anschaut. Die Anzahl der erstellten Fragen ist so gering wie zuletzt vor über 16 Jahren (Diskussion bei HN).
Passend dazu ist das neue OpenAI Modell GPT-5.6 Sol nun aus seinem Harness ausgebrochen und hat selbstständig eine Cyberattacke durchgeführt (Artikel bei der Zeit). Dazu gibt es bei OpenAI selbst auch einen interessanten Blog Artikel.
Alphabet hat als erster Hyperscaler Quartalszahlen veröffentlicht: Google Cloud legt im Q2 um 82 % auf 24,8 Milliarden Dollar zu und übertrifft damit deutlich die erwarteten 64 % – gleichzeitig hebt Alphabet die Capex-Prognose für 2026 auf 195 bis 205 Milliarden an und meldet zum ersten Mal in der Firmengeschichte einen negativen Free Cashflow von 5,9 Milliarden Dollar (Yahoo Finance).
Ach und Stripe will neben PayPal nun auch bei OpenRouter zuschlagen – anscheinend für um die 10 Milliarden Dollar – Schnapper!
So, und nun viel Spaß mit der neuen Ausgabe!
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 182 habe ich mit Raphaela Franke von RaphRoxs gesprochen. Nach Jahren als Produktentwicklerin bei Engelbert Strauss und Schöffel hat sie gekündigt und ein Jahr später ihre eigene Marke gelauncht: Mountainbike-Bekleidung für Frauen, produziert in Italien und Portugal. Wir reden über das Jahr bis zum Launch, die Produzentensuche und ihr Wachstum ohne Ads-Budget. 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).
So, nun endlich die News der Woche in der Übersicht:
- State of Open Source AI: Der Gap schrumpft
- Januscape: OVHcloud rebootet die ganze Flotte
- Hollowbyte: 11-Byte-DoS gegen OpenSSL
- Hetzner testet LLM-Inferenz als Experiment
- Anwalt Jun verklagt MG-Importeur wegen GPL
- Airbus zieht kritische Daten aus der US-Cloud ab
- 1 Million Sandboxes: Modal gegen etcd und K8s
- Show HN: Bowling-Scoring mit ESP32 selbst gebaut
- Lagern wir zu viel Denken an KI aus?
Support the Newsletter
Übrigens kannst Du meine Arbeit nun auf Patreon supporten, mir ein Bier ausgeben oder mal auf meiner Amazon-Wunschliste vorbeischauen – Danke! Falls du Interesse hast, im Newsletter oder Podcast Werbung zu buchen, kannst du das auf passionfroot machen oder mir einfach ne E-Mail als Antwort auf den NL schicken.
Auf allesnurgecloud.com findest Du vorherige Ausgaben und den RSS-Feed.
Vielen Dank für Dein Interesse und wie immer freue ich mich über Feedback und Weiterempfehlungen.
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:
State of Open Source AI: Der Gap schrumpft
Mozilla legt mit dem State of Open Source AI Report eine Bestandsaufnahme zur offenen KI vor – und CTO Raffi Krikorian macht keinen Hehl aus der Haltung: Open Weights seien Exit-Rechte. Ein Modell auf eigener Hardware könne niemand abschalten, einen gemieteten Endpunkt schon.
Konkret dokumentiert der Report mehrere Verschiebungen:
- Capability-Gap: von 8,04 % auf 3,3 % (Chatbot Arena) geschrumpft – bei Coding faktisch Parität, zurück liegt Open vor allem bei Reasoning und Agentic-Tasks
- Inferenzpreis: 50× gefallen in 36 Monaten, von 20 auf 0,40 Dollar pro Million Tokens
- Token-Volumen: Auf OpenRouter laufen mehrheitlich Open-Weight-Modelle, die fünf volumenstärksten sind allesamt offen
- Praxis: Stripe senkte die Inferenzkosten um 73 % durch Open Models auf vLLM; Microsoft und Uber deckelten ihre Token-Rechnungen
Krikorian versteckt die Schwachstellen nicht – „a case that hides its weak points is an advertisement“. Und die liegen im Betrieb: Nur 51 % der Open-Model-Teams schaffen es in Produktion, gegenüber 63 % bei Closed. Es hakt nicht am Modell, sondern an Tooling, Standardisierung und Enterprise-Readiness – und am Harness, jener Orchestrierungsschicht, in der die Closed-Labs gerade Modell und Scaffold zu einem gemieteten Produkt verschweißen.
Wie real das Abschalt-Risiko ist, illustriert der Report am Fable-5-Fall: Drei Tage nach Verkaufsstart zwang eine Export-Anordnung Anthropic, den Zugang für ausländische Nutzer zu kappen – wer darauf gebaut hatte, saß plötzlich vor einem toten Endpunkt.
In Ausgabe 201 kam Self-Hosting bei Steinbergers Kostenrechnung noch klar als unwirtschaftlich raus – der Report argumentiert, dass sich genau diese Rechnung gerade dreht. Sehe ich nun auch häufiger in der Praxis, dass sich Firmen kleine Spark Maschinen ins „Büro Rack“ schrauben und dann umlimitiert Tokens verbraten können.
Januscape: OVHcloud rebootet die ganze Flotte
Zero Impact war keine Option. So beginnt OVHclouds ungewöhnlich detailliertes Post-Mortem zur Patch-Kampagne für CVE-2026-53359, intern Januscape. Die Use-after-free-Lücke im Shadow-Paging-Subsystem von KVM x86 trifft jeden x86-Linux-Kernel vor dem Fix-Commit, distributionsunabhängig. Ein interner Test legte einen ungepatchten Host in rund zwei Minuten lahm. Betroffen: zehntausende Hypervisor mit etwa einer Million VMs.
Vier Alternativen wurden verworfen:
- Auf offizielle Kernel warten – der Zeitplan läge bei Dritten
- Live Patching – die nötige Kernel-Konfiguration senkt das Hardening-Niveau und erschwert die Erkennung einer Kompromittierung
- Nested Virtualization deaktivieren – wirksam, aber die Kundennutzung ist nicht einsehbar, und Live-Migration braucht das Feature
- Alles live migrieren – sauber, im Flottenmaßstab aber eine Frage von Monaten
Geblieben ist Backport plus Reboot, ohne Einzelzustimmung der Kunden. Klug ist die Reihenfolge: erst der Patch flottenweit, dann die Reboot-Welle. Wird die Lücke zwischenzeitlich ausgenutzt, crasht der Host, startet neu und zieht den Patch damit selbst.
Der Rollout startete in Sydney – kleine Region, Nachtzeit vor Ort, Bürozeit in Europa – und folgte dann der Sonne. Stop-Thresholds begrenzten gleichzeitig ausgefallene Hosts auf 15 in dichten Regionen, sonst auf 5. Ein Co-Location-Graph sollte verhindern, dass zwei Hosts desselben Kundenprojekts zeitgleich neu starten, allerdings nur best effort.
Lehrreich sind die Pannen: libvirt-guests stoppte Instanzen ohne Sync mit der Nova-API, erzwungene Reboots mitten im Disk-Write korrumpierten Daten – das Graceful-Shutdown-Fenster wuchs daraufhin auf 60 Sekunden.
Unbefriedigend bleibt die Kommunikation. Eine Status-Page unterblieb zunächst bewusst, um die Reboot-Sequenz nicht zu exponieren – nachvollziehbar, aber teuer: Bei GRA6 mit fast 90.000 nicht kontaktierten Kunden erfuhren manche vom Ausfall erst, als er da war.
Nach elf Tagen war die Flotte gepatcht. In Summe trotzdem ganz schön lange für so einen „Knaller“ Bug, bei dem unter Umständen aus der Gast VM auf den Host ausgebrochen werden konnte.
CVE-2026-53359 (Januscape) patching campaign
Anzeige
We Manage & KRUU: Cloud für unter 0,5 % des Umsatzes
Gemeinsam mit unserem Kunden KRUU – dem nach eigenen Angaben weltweit größten mobilen Fotoboxvermieter – haben wir eine ausführliche Case Study veröffentlicht (PDF).
5.000 Fotoboxen in neun EU-Ländern und den USA, bis zu 800 Versendungen pro Tag in der Hochsaison, über 99,99 % Server-Uptime – und das alles bei IT-Kosten von unter 0,5 % des Jahresumsatzes (inkl. We Manage). Statt auf AWS zu setzen, was laut KRUU-Gründer Philipp Schreiber „Faktor 10 bis 20 teurer“ wäre, haben wir eine Multi-Provider-Architektur aus Gridscale, Hetzner und DigitalOcean aufgebaut, die saisonal mitatmet und wirtschaftlich bleibt.
Was mich an der Zusammenarbeit nach 10 Jahren besonders freut: Philipp und ich kennen uns noch aus dem Heilbronner Nachtleben – und die Philosophie hat sich nie geändert. Stabile Technologien. Kein Overengineering. Kein Overprovisioning.
Wenn du auch ein skalierbares Setup ohne Hyperscaler-Preise suchst – oder schlicht ein Backup für dein Ein-Personen-DevOps-Team brauchst, dann lass uns kurz sprechen.
Die vollständige Case Study lesen
Hollowbyte: 11-Byte-DoS gegen OpenSSL
Elf Byte genügen, um einen Server in die Knie zu zwingen. Sicherheitsforscher von Okta haben eine unauthentifizierte DoS-Lücke in OpenSSL gefunden, von Golem unter dem Namen „Hollowbyte“ beschrieben. Der Angriff setzt am TLS-Handshake an: Die Client-Hello-Nachricht enthält einen 4-Byte-Header, der die Größe des folgenden Nachrichtenkörpers angibt. Ältere OpenSSL-Versionen reservieren daraufhin Speicher – bis zu 131 KB pro Anfrage –, bevor die Daten überhaupt eintreffen.
Der Worker-Thread wartet dann auf Daten, die nie kommen, und gibt den Speicher erst beim Verbindungsabbruch frei. Verschärft wird das durch glibc, die kleine bis mittelgroße Allokationen nicht sofort ans Betriebssystem zurückgibt. Über zufällig gewählte Größen bleibt der RAM belegt, selbst nachdem der Angreifer die Verbindung gekappt hat. Laut Okta hilft dann nur eins: „den Prozess zu beenden“.
Die Wirkung ist handfest: Einen Nginx mit 1 GB RAM legten die Forscher komplett lahm, bei 16 GB blockierten sie 25 %. Übliche Verbindungslimits boten keinen Schutz – ein sauberer Config-Workaround existiert also nicht.
Gepatcht ist die Lücke seit dem 9. Juni mit OpenSSL 4.0.1, zurückportiert auf 3.6.3, 3.5.7, 3.4.6 und 3.0.21. Wichtig für die Praxis: OpenSSL ist eine geteilte Bibliothek. Das Paket-Update allein reicht nicht – alle abhängigen Dienste müssen neu gestartet werden, sonst laufen sie mit der alten, verwundbaren Version im Speicher weiter. Betroffen sind neben Nginx und Apache auch Laufzeiten wie Node.js, Python, Ruby und PHP sowie MySQL und PostgreSQL.
OpenSSL-Bug lässt Speicher von Servern volllaufen
Hetzner testet LLM-Inferenz als Experiment
Kein Billing, kein SLA, ein einziges Modell: Hetzners neues Inference-Angebot ist ausdrücklich als Experiment deklariert. Jonas Scholz von Sliplane hat es sich angeschaut – die API ist OpenAI-kompatibel, Token erzeugt man im Experiments-Dashboard, dann zeigt der OpenAI-Client auf Hetzners Base-URL.
Serviert wird Qwen3.6-35B-A3B-FP8, ein MoE-Modell mit 35 Milliarden Parametern, davon 3 Milliarden aktiv, 262K Kontext, Text und Bild. Die FP8-Gewichte belegen rund 38 GB; bei FP16 wären es grob 70 GB, mit 4-Bit-Quantisierung landet man bei etwa 20 GB. Auf eine RTX PRO 6000 mit 96 GB passt das bequem – auf die 20-GB-RTX-4000 aus Hetzners kleinerem GPU-Server nicht.
Jonas‘ Messwerte: 153 ms Median bis zum ersten Token, 224 Output-Tokens pro Sekunde. Schnell, aber ein Einzeltest ohne Last. Das Modell selbst nennt er nüchtern klein und mäßig – zwei simple Rechenaufgaben gingen daneben.
Interessanter als das Modell ist die Frage nach dem Warum. Jonas spekuliert dabei offen und ohne Insiderwissen: Inferenz auf offenen Gewichten sei Commodity, Marge gebe es nur über Hardwarekosten und Auslastung. Genau das ist Hetzners Kerngeschäft – und ein geteilter Endpunkt hält GPUs beschäftigt, die als dedizierter Mietserver brachliegen würden.
Der Haken bleibt die Hardware. Für wirklich große offene Modelle – GLM-5 mit 754 Milliarden Parametern verteilt sich offiziell auf acht GPUs – braucht es B200-Klasse und schnelle Interconnects. Die hat Hetzner öffentlich nicht im Katalog. Bleibt es bei ein, zwei kleinen Modellen, ist es eine nette Fingerübung. Passend zum Mozilla-Report weiter oben: Europäische Kapazität entsteht nicht durch Absichtserklärungen, sondern durch GPU-Einkauf.
Den GEX131 mit der 96-GB-Blackwell-Karte hatte ich in Ausgabe 217 vorgestellt.
Anwalt Jun verklagt MG-Importeur wegen GPL
Alle baugleichen MG4 Electric ließen sich nicht legal betreiben – mit dieser steilen These hat der Würzburger IT-Anwalt Chan-jo Jun den Importeur SAIC Deutschland verklagt. Jun ist kein Unbekannter: bekannt geworden durch seine Verfahren gegen Facebook, gilt er vor allem als einer der profiliertesten deutschen Spezialisten für Open-Source-Lizenzrecht.
Der Vorwurf: Der MG4 laufe auf Open-Source-Software – unter anderem dem Linux-Kernel – und SAIC müsse auf Anforderung den Quellcode herausgeben. Genau das verweigere der Hersteller seit über einem Jahr; ein im Februar nachgerüsteter QR-Code zur Software-Anforderung habe nie etwas geliefert. Jun vermutet inzwischen, der Zustand lasse sich gar nicht mehr legalisieren, die Hardware müsste getauscht werden – die typische Folge, wenn Copyleft-Compliance schon bei der Komponentenauswahl ignoriert wird.
Neu ist die Konstruktion: Hier klagt nicht der Rechteinhaber, sondern der Käufer, gestützt auf § 435 BGB (Rechtsmangel). Der Käufer dürfe verlangen, dass kein Dritter urheberrechtliche Ansprüche gegen ihn geltend macht. Verhandelt wird im Oktober vor der 42. Zivilkammer des Landgerichts München I – jener Urheberrechtskammer, die im November auch GEMA ./. OpenAI entschied. Zwei Monate zuvor wird in den USA das Parallelverfahren SFC ./. Vizio verhandelt.
Nicht alle teilen die Zuspitzung. X-Nutzer @Jus799 hält dagegen, ein GPL-Verstoß mache aus dem Fahrer noch keinen Betreiber eines „illegalen Autos“ – die Pflichten lägen beim Hersteller. Ob das Gericht Juns Lesart folgt, klärt sich im Oktober.
Beitrag von Anwalt Jun via xcancel
Airbus zieht kritische Daten aus der US-Cloud ab
Airbus macht bei seiner angekündigten Cloud-Migration ernst. Wie Golem berichtet, verlagert der Konzern eine erste Gruppe geschäftskritischer Anwendungen von AWS zum französischen Anbieter Scaleway. In Phase eins wandern 70 Anwendungen, insgesamt geht es um rund 900 Systeme, die Airbus intern als „Minimum Viable Company“ führt – ERP, CRM, Fertigungssteuerung und Product Lifecycle Management, also unter anderem Flugzeugdesigns.
Digitalchefin Catherine Jestin nennt als Gründe technische Leistung und finanzielle Konditionen, die die großen Hyperscaler geschlagen hätten; zusätzlich habe Scaleway zugesagt, Airbus in seine Produkt-Roadmap einzubinden. Der Kontext ist der übliche: Der US CLOUD Act erlaubt US-Behörden den Zugriff auf Daten von US-Konzernen, unabhängig vom Serverstandort.
Der Realismus dahinter ist auffällig. Nicht alles zieht um: Skywise, die Luftfahrtdaten-Plattform, bleibt bei AWS, ebenso ein System für technische Kundenanfragen. Und generell verabschiedet sich Airbus nicht von US-Anbietern – Microsoft, Google, Salesforce, Coupa und Workday bleiben im Einsatz, entschieden werde einzeln nach Sensibilität der Daten.
Der treffendste Punkt kommt beiläufig: Ein Microsoft-Manager sagte vor einem französischen Gericht unter Eid aus, man könne Souveränität im Rahmen der bestehenden Verträge nicht vollständig garantieren. Genau das untergräbt die „Sovereign Cloud“-Angebote der Hyperscaler – ein Muster, das sich durch die ganze Debatte zieht.
Die erste Phase dieser Geschichte hatte ich in Ausgabe 218 vorgestellt – damals noch mit Airbus‘ eigener 80:20-Einschätzung, überhaupt einen passenden Anbieter zu finden.
Airbus schickt sensible Daten in die französische Cloud
1 Million Sandboxes: Modal gegen etcd und K8s
Agents laufen in Sandboxes, und „agents are eating software“ – mit dieser Prämisse begründet Modal im eigenen Blog, warum man die komplette Sandbox-Plattform neu gebaut hat. Ziel: 1 Million gleichzeitige Sandboxes, erzeugt in unter einer Minute, mit zehntausenden Neustarts pro Sekunde. Getrieben wird das von Reinforcement Learning und Background-Agents, die zum Rollout-Start Bursts von hunderttausenden Sandboxes erzeugen.
Interessant ist vor allem die Begründung, warum bestehende Lösungen das nicht leisten. Bei Kubernetes ist das Scheduling im Worst Case O(n×p) und standardmäßig serialisiert, jeder Pod schreibt mehrfach in etcd, und schon die Node-Heartbeats erzeugen etcd-Last unabhängig von der Pod-Erzeugung – shardbar ist etcd nicht trivial. Modals altes System litt an derselben Stelle: unsharded Postgres im kritischen Pfad jeder Sandbox-Erzeugung.
Die Lösung ist konsequent: zentrale Koordination raus, globale Konsistenz gegen Skalierbarkeit getauscht. Scheduling läuft über eine horizontal skalierte Server-Flotte gegen In-Memory-Daten – näher an Load Balancing als an klassischem Scheduling. Jeder Worker ist seine eigene Source of Truth und publiziert seinen Zustand in einen Redis-Stream; Datastores liegen nicht mehr im kritischen Pfad der Erzeugung.
Lehrreich ist ein Praxis-Detail: Die neuen Scheduler drückten Container so schnell auf die Worker, dass gleichzeitige Starts um den rtnl-Lock im Linux-Kernel konkurrierten – das Netzwerk-Setup dauerte plötzlich zehn Sekunden. Modal musste das Container-Networking umbauen.
Die „infinite scale“-Rhetorik nimmt man mit der üblichen Vorsicht. Eine Median-Startzeit unter 0,5 Sekunden bei einer Million Sandboxes ist aber ein solides Ergebnis. PayPal zeigte in Ausgabe 50, wie viel Arbeit nötig ist, etcd überhaupt auf 4.000 Nodes zu bekommen – ist aber auch schon ein Weilchen her.
Scaling to 1 million concurrent sandboxes in seconds
Show HN: Bowling-Scoring mit ESP32 selbst gebaut
Ein Site Reliability Engineer, der nebenbei ein Bowlingcenter betreibt – diese Kombination liefert einen der meistdiskutierten Show-HN-Beiträge der Woche. User section33 kaufte mit seiner Familie ein verlassenes 8-Bahnen-Center im ländlichen Mittleren Westen. Das Scoring-System von 2008 kostete damals sechsstellig; ein 1:1-Ersatz liegt heute bei 80.000 bis 120.000 Dollar.
Der Kern der Sache: Die 70 Jahre alten Pinsetter-Maschinen brauchen nur ein einziges Relais als Auslöser, alles andere ist Mechanik. Den Rest baute er mit Standardhardware nach – ESP32-Controller per ESP-NOW vernetzt, RS485 als kabelgebundenes Fallback, ein Raspberry Pi mit Redis und State Machine als Lane-Computer, darüber eine React-UI. Statt sechsstellig kostet das rund 1.600 Dollar. Quelloffen werden soll der Stack als OpenLaneLink.
Die Community griff vor allem das Muster dahinter auf. User madaxe_again ersetzte ausgefallene behördliche Pegelmesser – einst 100.000 Euro pro Station – durch ESP32-Bauten für rund 80 Euro das Stück; berkes nennt Theatertechnik, Fabriksteuerungen und Kühlhäuser als weitere Felder, in denen Lock-in-Hardware zu Mondpreisen verkauft werde.
Skepsis fehlte nicht: nativeit hält ein paar Dutzend ESP32 über Jahre nicht für zuverlässig genug im Dauerbetrieb, 0xbadcafebee fragt trocken, wen man bei einem Ausfall anrufe – sich selbst. Der Einwand ist fair: Der sechsstellige Preis kauft eben auch Support, Ersatzteillager und Haftung.
Show HN: I replaced a $120k bowling center system with $1,600 in ESP32s
Lagern wir zu viel Denken an KI aus?
Mit der Hand geschrieben, im Flugzeug, ohne Internet und ohne KI – so entstand der Essay von Yennie Jun, die bei Google an der Bewertung von Geminis Fähigkeiten arbeitet. Ihre Frage: Lagern wir zu viel unseres Denkens an KI aus?
Aufhänger ist Ken Lius Kurzgeschichte „The Perfect Match“ von 2012, in der ein KI-Assistent sämtliche Entscheidungen für seinen Nutzer trifft – vom Frühstück bis zur Partnerwahl. Das reale Gegenstück lieferte ein Startup-Gründer auf einem SF-Event: ein Mikrofon am Hemd, das alle Gespräche aufzeichnet und abends von einer KI auswerten lässt. Seine Begründung: Die KI denke besser als er, also überlasse er ihr das Denken. Nebenbei baut sein Startup ein Geschäft daraus, auch das Denken anderer Leute abzugreifen – ohne deren Zustimmung.
Der Kern ist kein KI-Bashing. Jun arbeitet selbst im Feld und nennt konkrete Vorteile: Übersetzungen, Coding-Agents, ein personalisierter MCAT-Tutor. Lesenswert ist ihre Unterscheidung: In Portugal wollte ihre Schwester eine Frage sofort an ChatGPT geben; stattdessen spekulierten beide erst selbst, stellten Hypothesen auf, widersprachen sich – und zogen die KI erst danach hinzu, um die eigenen Thesen zu prüfen und zu erweitern.
Da liegt die Grenze zwischen Assistenz und Autonomieverlust: Wer die Zwischenschritte – Frage zerlegen, Quellen bewerten, synthetisieren – dauerhaft auslagert, bekommt fertige Antworten, verlernt aber den Weg dorthin. Juns Schlussfrage: Automatisieren wir „human tasks or human thinking?“
Are we offloading too much of our thinking to AI?
Schmunzelecke
Der einfache Browser Airport Simulator zeigt die Challenges eines Flughafens – wie viele Landungen hast du geschafft? (Du musst die Flugzeuge zur passenden Landebahn ziehen, startenden Fliegern ausweichen und die Landenden dürfen sich auch nicht in die Quere kommen).
💡 Link Tipps aus der Open Source Welt
Uncloud – Container Orchestration ohne Kubernetes-Overhead
Uncloud ist ein leichtgewichtiges Clustering- und Container-Orchestrierungstool, das Docker-Hosts über ein automatisches WireGuard-Mesh verbindet – Cloud VMs, Bare Metal und Heimserver in einem Cluster, ohne Kubernetes, ohne Swarm, ohne zentralen Control Plane.
Key Features:
- Dezentralisiert: Kein Control Plane, kein Quorum. Jede Maschine hält eine synchronisierte Kopie des Cluster-State via Peer-to-Peer (Corrosion/SQLite). Cluster funktioniert weiter, auch wenn Maschinen offline gehen
- Docker Compose Format: Services in bekanntem Compose-YAML definieren, kein neues DSL lernen
- Zero-Config WireGuard Mesh: Automatische Peer Discovery und NAT Traversal, Container bekommen einzigartige IPs für direkte Cross-Machine-Kommunikation
- Automatic HTTPS: Eingebauter Caddy Reverse Proxy mit Let’s Encrypt Zertifikaten
- Unregistry: Docker Images direkt auf die Maschinen pushen ohne externe Registry – nur fehlende Layer werden übertragen
- Zero-Downtime Deployments: Rolling Updates ohne Service-Unterbrechung
- Managed DNS: Automatische
*.uncld.devDNS Records für Services mit Public Access - Imperativ statt Deklarativ:
uc run,uc rm,uc ls– Docker-ähnliche CLI statt endloser YAML-Reconciliation
Workflow: uc machine init root@server → uc run -p app.example.com:8000/https image/my-app → fertig.
Uncloud besetzt genau die Lücke zwischen „ein Docker Host reicht nicht mehr“ und „Kubernetes ist Overkill“. Der dezentrale Ansatz ohne Control Plane eliminiert den größten Ops-Aufwand bei kleinen bis mittleren Setups. Inspiriert von Kamal, Fly.io und Tailscale – und das merkt man: die Developer Experience fühlt sich an wie ein Cloud-PaaS, nur auf eigener Infrastruktur. Für Teams mit 2-20 Servern, die nicht in Kubernetes investieren wollen, aktuell die spannendste Option.
https://github.com/psviderski/uncloud
CrawlSEO – Open Source SEO Monitoring zum Selbsthosten
CrawlSEO bündelt Google Search Console Analytics, Site Crawler, Core Web Vitals und MCP Server in einem self-hosted Dashboard – kostenlos, für Gründer und Entwickler, nicht für SEO-Spezialisten.
Key Features:
- GSC Analytics: Keywords, Pages, Clicks, Impressions, Position Tracking mit 28-Tage-Vergleich und Delta-Indikatoren
- Site Crawler: Bis zu 2.000 Seiten mit Concurrent Fetching, Health Score, 16 Issue-Typen, Content Scoring und Remediation-Hinweisen
- Core Web Vitals: LCP, CLS, INP, TTFB via PageSpeed Insights mit Mobile/Desktop-Vergleich
- Keyword Research & Backlinks: Via DataForSEO (Bring Your Own Key), Google Autocomplete als kostenloser Fallback
- SEO Opportunities: Striking-Distance Keywords, Low CTR, Content Decay, Cannibalization Detection
- Alerts: Traffic Drops, Position Changes, neue 404s, Vitals-Verschlechterung – per Email, Slack, Telegram oder Webhook
- MCP Server: 10 Tools für Claude Code, Claude Desktop und Cursor – SEO-Daten direkt aus dem Terminal abfragen
Tech Stack: Next.js 16, TypeScript, PostgreSQL, Prisma, NextAuth.js v5, shadcn/ui. Deployment via Docker Compose.
Für Indie Hacker und kleine Teams, die SEO-Basics monitoren wollen, ohne 119€/Monat an Ahrefs oder 139$/Monat an Semrush zu zahlen. Die MCP-Integration macht es besonders interessant für Entwickler, die SEO-Daten in AI-Agent-Workflows einbinden wollen. Noch früh (kein Release, 4 Contributors), aber der Feature-Scope ist für ein 3 Monate altes Projekt beachtlich.
https://github.com/crawlseo/crawlseo
❓ Feedback & Newsletter Abo
Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.
Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!
Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: