Willkommen zu allesnurgecloud.com – Ausgabe #238

So, das ist die letzte, dafür sehr ausführliche Ausgabe im Mai – und dann bin ich erst mal eine Woche im wohlverdienten Urlaub.

Brauchen wir eigentlich Urlaub von AI? Hier schreibt Blogger orchid jedenfalls, warum er „tired of talking to AI“ ist. Ein weiterer Blogger fragt provokant, ob wir nun alle einen Tag freibekommen, da sich die Produktivität ja erhöht habe. Freitag könne ja der „AI Workers Day“ werden. Tja, ganz so schnell geht es wohl dann doch nicht. Und schließlich schreibt ein Dritter, dass „AI is just unauthorised plagiarism at a bigger scale“ sei – alle, die im Content-Bereich unterwegs sind, werden hier sicherlich zustimmen.

In eigener Sache (ja, schon wieder – sorry): Ich baue gerade selbst an einem kleinen SaaS – einer komplett in Deutschland betriebenen StatusPage namens Statuswerk. Alle Daten werden hierzulande verarbeitet und verschickt (E-Mail, SMS), der Fokus liegt bewusst nur auf der Status Page – dafür richtig gemacht und zu einem attraktiven Preis. Wer sowas sucht: auf der Warteliste eintragen lohnt sich, zum Launch im Juni gibt’s ein Early-Bird-Angebot.

So, und nun viel Spaß mit Ausgabe der prall gefüllten Urlaubsausgabe #238 und schöne Pfingstferien, falls du auch weg bist!

Happy Bootstrapping Podcast

In der aktuellen Podcast Folge 174 habe ich mit Anna Yona von Wildling Shoes gesprochen. Anna hat das Unternehmen vor elf Jahren mit ihrem Mann Ran gegründet – Minimalschuhe, entstanden aus einer Idee für die eigenen Kinder. Heute verkauft das Familienunternehmen aus dem Oberbergischen rund 500.000 Paar pro Jahr, komplett remote, ohne Amazon und ohne Handel. Wir reden über die Crowdfunding-Kampagne, die in 24 Stunden das Ziel sprengte, das Wachstum allein über Weiterempfehlung und die harte Phase, in der das Team von fast 300 auf 80 Menschen geschrumpft ist. 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:

RAMpocalypse: Preiswelle erreicht alle Hoster

Die im Januar in Ausgabe 218 beschriebene Speicherkrise schlägt jetzt flächendeckend auf die Endkundenpreise durch. Innerhalb weniger Wochen haben gleich vier europäische Hoster Preiserhöhungen angekündigt – mit erstaunlich gleichlautender Begründung. Wobei „Chipmangel“ zu pauschal ist: Es handelt sich primär um eine DRAM- und NAND-Knappheit, weil Samsung, SK Hynix und Micron inzwischen rund 93 % ihrer Fertigung auf High-Bandwidth-Memory für AI-Rechenzentren umgelenkt haben. Die DRAM-Preise sind allein in Q1 2026 um 90 % gegenüber dem Vorquartal gestiegen. Zunehmend greift die Knappheit auch auf CPUs über, deren Bedarf für AI-Workloads ebenfalls explodiert – ein echter Logic-Chipmangel wie 2021 ist es aber nicht. SocketSocket

Die nüchternste Analyse liefert OVH-Gründer Octave Klaba in einem ausführlichen Blogpost: RAM-Preise könnten je nach Konfiguration 15 bis 300 % über dem 2025er-Niveau liegen, eine Normalisierung sei nicht vor 2028 zu erwarten. Provider müssen inzwischen bis zu zwölf Monate im Voraus bestellen, ohne den finalen Preis zu kennen.

Die Ankündigungen im Überblick:

• OVHcloud: Durchschnittlich nur 9–11 % Aufschlag für 2026–2028 deployte Hardware, 2–6 % auf ältere Deployments, plus IPv4-Anpassung. Ab 1. April; Bestandskunden können vorher bis zu zwei Jahre zum Altpreis verlängern.
• Hetzner: Standardisierung des Dedicated-Portfolios auf feste Typen (-1/-2/-3), individuelle RAM-/Storage-Konfigurationen entfallen, dazu ein neuer „Limited“-Typ aus günstig beschaffter Hardware. Ab 15. Juni steigen auch die Preise sämtlicher Cloud Server (Neubestellungen und Rescales) – mit explizitem Hinweis, die Vorlaufzeit für Anpassungen an der API-Provisionierung zu nutzen.
• netcup: Am deutlichsten – Bestandsverträge +18,51 %, Neubestellungen +24,33 %, Storage einheitlich +21,52 %. Ab 1. Mai bzw. 19. März.
• Scaleway: Produktspezifisch – Compute moderat (+1–2 %), GPU +5–10 %, aber Netzwerk drastisch: Load Balancer +44–46 %, externe DNS-Zonen +600 %. Ab 1. Juni.

Auffällig ist der Tonfall: OVH und Scaleway verpacken die Erhöhung in viel Transparenz-Prosa über „Partnerschaft“ und „bulletproof resiliency“, netcup bleibt mit den nackten Prozentzahlen am ehrlichsten.

Offen ist die spannendste Frage: Was machen die Hyperscaler? AWS hat im Januar bereits GPU-Preise um 15 % erhöht (Ausgabe 218) – an einem Samstag, in der Hoffnung, dass es niemand merkt. Azure, GCP und AWS kaufen RAM auf demselben leergefegten Markt, verstecken die Mehrkosten aber bislang im AI-Margenpolster und in der Komplexität ihrer Preislisten, statt sie wie die europäischen Hoster offen auszuweisen.

Für Self-Hoster heißt das: Bestandskonditionen sichern, wo möglich, oder halt optimieren, wo es geht. Die Hardware Server bei Hetzner bieten noch immer viel Leistung fürs Geld – und wenn die Server nun standardisiert werden, ist das vielleicht auch gar nicht verkehrt, da es aktuell vielleicht einen Tick zu individuell ist.

---

Railway: 8 Stunden Downtime durch GCP-Account-Suspendierung

Der PaaS-Anbieter Railway erlebte am 19. Mai einen achtstündigen Komplettausfall, der außerhalb der bekannten Hyperscaler-Outage-Liste alle Aufmerksamkeit verdient – weil die Ursache so banal wie folgenreich war. Im offiziellen Postmortem beschreibt das Team, wie Google Cloud den Produktions-Account von Railway irrtümlich gesperrt hat, im Rahmen einer automatisierten Aktion, die laut Railway „viele Accounts“ innerhalb von GCP betraf. Vorab-Information an die Kunden: keine – ob hier die Terminator AI zu gründlich war? Man weiß es nicht.

Der eigentliche Schmerzpunkt ist aber nicht die Sperrung selbst, sondern die Kaskade. Railways Edge-Proxys cachen Routing-Tabellen vom Network Control Plane, der auf GCP läuft – Workloads auf Railway Metal und AWS liefen anfangs weiter. Als die Cache-TTLs abliefen und die Control Plane nicht mehr antwortete, konnten auch diese Workloads nicht mehr aufgelöst werden. Ergebnis: 404-Fehler über alle Regionen, auch dort, wo physisch nichts kaputt war. Der Account-Zugriff war nach 9 Minuten zurück, die vollständige Wiederherstellung von Disks, Compute und Netzwerk dauerte trotzdem bis 06:14 UTC – obendrauf rate-limitete GitHub Railways OAuth- und Webhook-Integrationen, weil die Retry-Wellen den API-Limit sprengten.

Was Railway daraus lernt: echter Mesh statt Pseudo-Mesh zwischen Metal, GCP und AWS, HA-Datenbank-Shards über AWS und Metal verteilt, GCP nur noch im sekundären Pfad. Was der Vorfall jenseits davon zeigt: Account-Sperrungen ohne Vorwarnung sind bei Google Cloud ein Muster, kein Einzelfall. Über UniSuper hatte ich in Ausgabe 145 berichtet – ganzer Account inklusive Backup gelöscht; über die dreimalige SSLMate-Suspendierung in Ausgabe 212 ebenfalls.

Railway nimmt die Verantwortung sportlich auf sich („we ultimately own this one“), aber die eigentliche Frage lautet: Wer baut seine Plattform freiwillig auf einem Provider, der per automatisierter Routine Accounts abschalten kann? Und den Kunden nicht mal vorwarnt? Ich dachte, dafür gibt es dann Key-Account-Manager für die größeren Accounts?

Incident Report: May 19, 2026- GCP Account Suspension

---

---

35.000 Dollar Google Cloud durch acht Mac minis ersetzt

Bevor Google dir den Cloud Account sperrt, kannst du deine Workload vielleicht auch auf Mac Minis umziehen. Yembo-CTO Zach Rattner hat jedenfalls seine Cloud-Repatriation-Story auf LinkedIn fortgeschrieben: Aus dem ursprünglichen Zwei-Mac-mini-Setup für 35.000 Dollar jährliche Google-Cloud-Compute sind mittlerweile acht Mac minis geworden – M4 Pros mit 64 GB RAM für schwere Workloads, Base-M4 für Standard-Aufgaben. Drauf laufen self-hosted CircleCI- und GitHub-Action-Runner, das Backend von zachrattner.com inklusive Cronjobs, Playwright-QA und Speech-Transcription.

Die handfeste Zahl: Bei den GitHub Actions sank die Full-Repo-Build- und Lint-Zeit von vier Minuten auf 40 Sekunden – Faktor sechs. Rattners eigentliches Argument ist nicht die Kostenersparnis, sondern dass vier Minuten Wartezeit den Flow-State eines Engineers brechen, 40 Sekunden nicht. Die Mac minis werden wie Cloud-Instanzen behandelt: standardisiert, code-managed, mit Autoscalern in der Cloud als Fallback. Passend dazu die Effizienz-Zahlen aus Ausgabe 165: Jeff Geerling hatte den M4 mini bei 6,74 GFlops/Watt und 3-4 Watt Idle gemessen.

Ehrlich macht Rattner die Sache, indem er widerspricht, sobald jemand das Repatriation-Pathos zu weit treibt: Für agentic Coding und große Prompt-Workflows nutze er weiterhin Cloud-Modelle. Cloud bleibe das richtige Werkzeug für variable Workloads, nur sei das unbegrenzte Mieten von Compute für vorhersehbare Baseline-Operations ein „massive capital leak“. Setup-Details gibt’s in seinem Schritt-für-Schritt-Guide.

Na, hast du auch schon deinen Cluster bestellt?

A few months ago, I moved $35,000 of annual Google Cloud compute to two Mac minis.

---

Airbnb: Zirkuläre Abhängigkeiten im Observability-Stack

Im Airbnb Engineering Blog beschreibt Abdurrahman J. Allawala ein Problem, das jede gereifte Observability-Stack-Diskussion früher oder später trifft: die zirkuläre Abhängigkeit. Wenn die Metrik-Pipeline auf demselben Kubernetes, demselben Service-Mesh und derselben Plattform läuft wie die überwachten Services, dann verschwindet die Sicht genau dann, wenn man sie am dringendsten braucht – Dashboards dunkel, Alerts stumm, Recovery im Blindflug.

Airbnbs Lösung läuft in drei Schichten. Compute kommt auf dedizierte Kubernetes-Cluster, die zwar weiterhin vom zentralen Cloud-Team administriert werden, aber nicht mit Produkt- oder Infrastruktur-Workloads geteilt sind – das vermeidet sowohl die zirkuläre Abhängigkeit als auch den Betriebs-Overhead eigener Cluster. Beim Netzwerk hat Airbnb das Istio-Service-Mesh komplett umgangen und einen eigenen Envoy-basierten Layer-7-Ingress gebaut, der Telemetrie-Traffic vom Business-Traffic trennt. Begründung: Observability-Verkehr ist um Größenordnungen volumiger als Geschäfts-Traffic – Mischbetrieb riskiert, dass Telemetrie-Spitzen Anwendungs-Traffic verdrängen und damit ironischerweise selbst zum Outage-Auslöser werden.

Am charmantesten ist der dritte Layer: das Meta-Monitoring mit Dead Man’s Switch. Ein separater Prometheus überwacht den Observability-Stack selbst, läuft auf isolierten Nodes in anderen AZs und feuert eine Dauer-Alarmregel, die als kontinuierliches Lebenszeichen an AWS SNS und CloudWatch fließt. Wenn das Signal abreißt – egal warum – schlägt CloudWatch Alarm und paged den On-Call. So vermeidet man den infiniten Regress des „wer überwacht die Überwacher“, indem man auf die Abwesenheit eines Signals als Trigger umstellt.

Architektur-philosophisch passt das zur Airbnb-Multi-Cluster-Datenbank aus Ausgabe 202: bewusst Failure Domains trennen, lieber etwas mehr Overhead in Kauf nehmen, statt sich auf einen einzigen Pfad zu verlassen. Übertragbar ist die Lektion auch für kleinere Setups: Wer sein Monitoring im selben Cluster wie die Anwendung laufen hat, bekommt im Ernstfall keine Antworten – sondern wartet auf Pages, die nie kommen, da kann man dann auch entspannt in Urlaub gehen. In Germany we call that „am eigenen Ast sägen“.

Monitoring reliably at scale

---

Niederlande beschlagnahmen 800 Server von Russland-Hoster

Wie Brian Krebs berichtet, hat die niederländische Finanzkriminalitätsbehörde FIOD am 18. Mai zwei Männer verhaftet und über 800 Server beschlagnahmt – wegen Verstoßes gegen Sanktionsrecht. Festgenommen wurden Andrey Nesterenko, Betreiber von MIRhosting, und Youssef Zinad aus Amsterdam. Durchsucht wurden zwei Rechenzentren in Dronten und Schiphol-Rijk.

Im Zentrum steht Stark Industries Solutions, ein Hosting-Provider, der zwei Wochen vor dem russischen Einmarsch in der Ukraine entstand und sich rasch zur Quelle massiver DDoS-Angriffe gegen europäische Ziele entwickelte. Nachdem die EU im Mai 2025 den ursprünglichen Zubringer PQHosting sanktionierte, wanderten die Netz-Assets auf eine neue Entität namens the.hosting unter der Dutch-Firma WorkTitans – angebunden ausschließlich über MIRhosting. Laut de Volkskrant waren beide die meistgenutzten Netze bei pro-russischen Angriffen auf dänische Behörden in der Woche der Kommunalwahlen im November 2025.

Pikant für die Kunden: Eine Meldung nach der Beschlagnahme teilte mit, dass die auf den Servern gespeicherten Daten verloren und nicht wiederherstellbar seien – ein Lehrstück darüber, wo man Workloads besser nicht hostet. Ähnlich wie beim CyberBunker-Verfahren aus Ausgabe 48 zeigt sich auch hier: Solche Netze verschwinden nicht durch eine Razzia, sie wandern weiter – diesmal von PQHosting zu the.hosting, beim nächsten Mal woandershin – ich bleibe dran und Brian Krebs erst recht.

Netherlands Seizes 800 Servers, Arrests 2 for Aiding Cyberattacks

---

Warum Post-Mortem-Action-Items meistens verschwinden

Kate Bernacchi-Sass beschreibt im Incident.io-Blog das, was sie das „Last-Mile-Problem von Post-Mortems“ nennt: Das Review läuft sauber, blameless, mit ehrlicher Timeline – und dann passiert nichts. Die Erkenntnisse landen im Dokument, das Dokument wird geschlossen, der nächste Incident kommt. Vier typische Sterbeursachen für Action-Items identifiziert sie: niemand ist konkret zuständig („das Team sollte…“ ist keine Aufgabe), die Action lebt am falschen Ort (im Post-Mortem-Doc statt in Linear/Jira), sie ist eine Richtung statt einer Aufgabe („Monitoring verbessern“ hat kein „fertig“), und niemand prüft nach.

Der Test für ein gutes Action-Item: Name, Verb, konkretes Ergebnis, Heimat im echten Tracker, Deadline. „Improve monitoring“ wird zu „Alice: add alert for DB replication lag >30s in Datadog, by end of sprint 14″. Verben wie review, explore, investigate beschreiben Aktivität, nicht Veränderung – besser sind add, remove, change, deploy. Die Schwierigkeit beginnt erst bei systemischen Findings: „Component X braucht klare Ownership“ lässt sich nicht im Sprint abarbeiten, sondern muss als konkrete Eskalation mit Risiko und Adressat formuliert werden – sonst rottet sie im Backlog.

Lesenswert ist die Unterscheidung von Blame und Accountability: Blame schaut zurück, Accountability nach vorn. „Alice hätte den Alert haben sollen“ ist Schuldzuweisung, „Alice baut den Alert bis Freitag“ ist Ownership. Diese Trennung ausdrücklich im Debrief zu benennen, reduziert die Defensive – passt zur Diskussion aus Ausgabe 178, in der ein Reddit-Thread herausarbeitete, dass schlechte Postmortems oft weniger ein Blame-Problem haben als ein Kontext-Problem.

Disclaimer: Der Beitrag stammt aus dem Incident.io-Vendor-Blog, der naturgemäß auf das eigene Tool zielt. Die Punkte sind aber tool-unabhängig nutzbar und ergänzen die Pitfalls-of-Post-Mortems-Diskussion aus Ausgabe 71.

Why post-mortem action items die

---

Mail-Use-Cases durch Subdomains trennen

Im neuen Blog-Artikel auf we-manage.de löse ich endlich ein, was ich in Ausgabe 130 angekündigt hatte: die Blog-Serie zu E-Mail-Validierung und Reputation. Aufhänger ist ein Problem, das ich in der Praxis ständig sehe – Unternehmen jagen Mitarbeiter-Mails, Newsletter und transaktionale Mails über eine einzige Domain und wundern sich dann, warum die Password-Reset-Mail im Spam landet.

Der Kern: Mailbox-Provider bewerten jede sendende Domain über Engagement-Signale. Eine Password-Reset-Mail wird zu fast 100 % geöffnet, ein Newsletter liegt bei soliden 25 %, Cold-Outreach irgendwo darunter. Wirft man alles auf dieselbe Domain, mittelt sich die Reputation – im schlimmsten Fall reißt eine schlecht gepflegte Newsletter-Liste die Zustellung der Rechnungs-Mails mit runter. Die Lösung ist die Trennung über echte Subdomains (nicht bloß noreply@ vs. newsletter@ – das ist für ISPs dieselbe Domain), jede mit eigenem Satz an SPF-, DKIM- und DMARC-Records.

Im Artikel zeige ich das durchgängig an einem aktuellen Laravel-Projekt, inklusive konkreter DNS-Beispiele, der Warmup-Strategie für neue Subdomains und – mir wichtig – europäischer Versand-Alternativen zu den US-Verdächtigen Postmark, SendGrid und SES: AhaSend, Lettermint, Scaleway TEM, dazu Self-hosting mit Postal aus Ausgabe 137. Außerdem der gern vergessene Punkt: nicht-sendende Domains per Null-MX, SPF -all und DMARC p=reject gegen Spoofing dichtmachen – vier DNS-Einträge, fünf Minuten, eine ganze Phishing-Klasse weg.

Sehe leider immer noch häufig in der Praxis, dass Firmen diese Best-Practices nicht umsetzen – manchmal ist es technische Schuld, die nie korrigiert wird, manchmal wird es einfach vergessen – einfach machen!

E-Mail-Reputation: Warum du deine Use-Cases auf Subdomains trennen solltest

---

Scaleway FR-PAR-2: 27 Stunden Ausfall durch Batterie-Defekt

Bei Scaleway in der Pariser AZ FR-PAR-2 ist am Freitag, 22. Mai um 11:21 CEST ein Komplettausfall in beiden Operator/Network-Rooms passiert – ausgerechnet während einer geplanten Datacenter-Wartung durch den DC-Betreiber. Folge: beide Netzwerk-Räume gleichzeitig stromlos, die komplette AZ isoliert. Betroffen waren Instances, Kapsule, Managed Databases, Object Storage, Serverless Containers/Functions und File Storage – außerdem Dedibox DC5 und temporär auch PAR-1 und PAR-3 während des Service-Transitions, wie aus der Status-Page hervorgeht.

Der DC fuhr auf Generatorbetrieb, Scaleway empfahl Kunden früh, Workloads in andere Regionen/AZs zu verlagern. Bis zum Freitagabend kamen die meisten Services schrittweise zurück – Instances und Object Storage gegen 16:30, Container/Functions gegen 14:00, File Storage mit Restart-Empfehlung an die Kunden. Der DC blieb das ganze Wochenende auf Generatoren, mit „enough fuel for a few days“ – beruhigend formuliert.

Die Root Cause klärte sich Samstag: defekte USV-Batterien. Der DC-Betreiber tauschte am Samstag ab 10:30 CEST live die Batterien auf allen vier Strompfaden, gegen 14:40 CEST war das Failback auf Hauptstrom durch und der nominale Zustand erreicht. Gesamtdauer vom Outage-Start bis zum Wiederherstellen des nominalen Zustands: rund 27 Stunden.

Batterien als Single Point of Failure sind im Pariser Cloud-Ökosystem keine Premiere. Beim Brand im Maxnod-Datacenter im März 2023 (Ausgabe 102) hatten die Batterien einer Photovoltaik-Anlage gebrannt, beim Cloudflare-Ausfall in PDX-04 (Ausgabe 123) brachen die Batterien nach 4 statt der versprochenen 10 Minuten zusammen. Hier nun also Scaleway: USV-Batterien, die ausgerechnet während einer Wartung versagen, in der sie eigentlich ihre Hauptaufgabe hätten erfüllen sollen.

Spannend wird der Postmortem von Scaleway – vor allem die Frage, warum ein USV-Defekt beide redundanten Operator-Räume gleichzeitig offline nehmen konnte. Genau das soll Redundanz auf Strompfad-Ebene eigentlich verhindern.

FR-PAR-2 connectivity loss

---

GitHub sperrt Zero-Day-Leaker Nightmare-Eclipse

Wie it-daily.net berichtet, hat GitHub das Konto des Sicherheitsforschers Nightmare-Eclipse (auch bekannt als Chaotic Eclipse) dauerhaft gesperrt. Vorausgegangen war eine ungewöhnliche Serie: Zwischen dem 2. April und Mitte Mai veröffentlichte der anonyme Akteur sechs Windows-Zero-Days ohne koordinierte Offenlegung – jeweils kurz nach dem monatlichen Patch Tuesday, gerne mit der nächsten Lücke direkt am Tag nach dem Update-Zyklus.

Die Liste ist ungemütlich: BlueHammer (lokale Privilege Escalation via Windows Defender, mittlerweile als CVE-2026-33825 gepatcht), RedSun (Defender-Logiklücke, ermöglicht Schadcode in Systemverzeichnissen), YellowKey (BitLocker-Bypass über manipulierten USB-Stick und WinRE), sowie MiniPlasma – und der ist besonders peinlich für Microsoft. MiniPlasma reaktiviert nämlich eine Lücke, die Google Project Zero 2020 als CVE-2020-17103 gemeldet hatte und die im Dezember 2020 als gepatcht galt – der Fix wurde laut Chaotic Eclipse „silent rolled back“ oder nie vollständig ausgerollt. Sicherheitsforscher Will Dormann hat bestätigt: Der ursprüngliche Google-PoC läuft auf Windows 11 mit aktuellen Patches und spawnt eine SYSTEM-Shell.

Nach der GitHub-Sperre wanderte das komplette Repository binnen Stunden auf GitLab, und der Forscher – der laut Register-Gerüchten ein ehemaliger Microsoft-Mitarbeiter sein könnte – verschärfte den Ton: Für den 14. Juli 2026 kündigt er die Veröffentlichung „vertraulicher Dokumente“ an, die dem Konzern „schweren Schaden zufügen“ sollen, im laufenden Juni weitere Exploits, falls Microsoft nicht einlenkt. Inhaltlich klingt das wie ein persönlicher Konflikt, kein klassisches Researcher-Vendor-Verhältnis.

Die Sperre selbst ist erwartbar – Microsoft besitzt GitHub, und Plattformregeln gegen das Hosten aktiver Zero-Days existieren. Trotzdem trifft die Maßnahme einen wunden Punkt: Eine Plattform für Open-Source-Forschung, deren Betreiber gleichzeitig Konfliktpartei ist, hat ein strukturelles Glaubwürdigkeitsproblem. Dass die Repos eine Stunde später auf GitLab wieder online waren, zeigt zudem, wie wenig das Banning operativ bringt – die Lücken sind in der Welt, mit oder ohne GitHub-URL.

GitHub sperrt Sicherheitsforscher nach Zero-Day-Leaks

---

GitLab 19.0: Neues Major-Release

Am 21. Mai erschien GitLab 19.0 – das erste Major-Release seit 18.0 und vor allem für Self-Managed-Betreiber ein Pflichttermin. Das Highlight-Feature ist die Integration von Claude Opus 4.7 in die GitLab Duo Agent Platform, samt Support für selbst-gehostete Gemini-Modelle und Open-Source-Modelle wie Devstral 2 123B und GLM-5.1-FP8 für offline und netzwerk-restriktierte Deployments.

Die weiteren Highlights:

• Claude Opus 4.7 in der Duo Agent Platform – für Code Review, Vulnerability Resolution und CI/CD-Flows (Premium + Ultimate)
• Self-hosted Gemini-Modelle – für die Duo Agent Platform Self-Hosted (Premium + Ultimate, Self-Managed)
• GitLab Secrets Manager als Open Beta – CI/CD-Secrets nativ in GitLab, scoped auf Projekt oder Gruppe (Premium + Ultimate)
• SBOM-basiertes Dependency Scanning GA – inkl. automatischer transitiver Resolution für Maven, Gradle und Python (Ultimate)
• Konfigurierbare Work-Item-Typen – eigene Typen wie User Story, Bug, Maintenance mit Custom Fields und Status-Lifecycles (Premium + Ultimate)
• Duo Core wechselt auf Usage-based Billing – Code Suggestions verbrauchen ab sofort GitLab Credits (alle Tiers)
• GitLab Credits auf dem Free-Tier (Self-Managed) – Duo Agent Platform ohne Premium/Ultimate-Abo zugänglich (Free, Self-Managed)
• Merge-Conflict-Resolution per Duo – analysiert, editiert, commitet, pusht (Beta, Premium + Ultimate)
• Webhooks per HMAC-SHA256 signieren – endlich Schluss mit Klartext-Token im Header, nach Standard Webhooks Spec (alle Editionen)
• Cross-Project-Pushes via CI_JOB_TOKEN – kein PAT mehr für Pushes in andere Projekte nötig (alle Editionen, Feature Flag)
• Rapid Diffs für MR-Reviews (Beta) – schnelleres Laden bei großen Changesets (alle Editionen)
• Auto-Remediation für Ruby-Dependencies (Experiment) – automatischer MR mit Patch-Update (Ultimate, GitLab.com)

Für Self-Managed-Admins ist das Release vor allem ein Aufräum-Release: PostgreSQL 17 wird Pflicht, Redis 6 fliegt raus (mindestens 7.2 oder Valkey 7.2), die Linux-Pakete für Ubuntu 20.04 und alle SUSE-Distributionen (openSUSE Leap 15.6, SLES 12.5/15.6) sind Geschichte – wer SUSE bleiben will, muss auf Docker umsteigen. Mattermost fliegt aus dem Linux-Paket, ebenso die gebündelten Bitnami-Charts für PostgreSQL, Redis und MinIO aus dem Helm-Chart. NGINX Ingress wird im Helm-Chart durch Gateway API mit Envoy Gateway ersetzt – bis GitLab 20.0 noch optional reaktivierbar.

Bei 2 Upgrades hatte ich Spaß mit der Registry, da die DB Migration nicht automatisch gelaufen ist – vielleicht ist bis zum Wochenende auch schon ein Fix da. Alle Änderungen wie immer auf der GitLab 19.0 Release Page.

BMDS vergibt Auftrag für souveräne KI-Cloud

---

Schmunzelecke

Cloud Imperium Games hat mit Star Citizen eine Milliarde Dollar eingesammelt – 14 Jahre Entwicklung, kein Release-Termin, dafür digitale Raumschiffe für 5.900 Dollar pro Stück. Squadron 42, ursprünglich für 2016 versprochen, soll inzwischen „von Anfang bis Ende spielbar“ sein – also fast fertig, nur halt noch nicht.

Die Stellar Navigation Chart vom Film „Project Hail Mary“ findest du hier online – cool gemacht!

---

💡 Link Tipps aus der Open Source Welt

Rowboat – AI Coworker mit persistentem Knowledge Graph

Rowboat ist ein local-first AI Coworker, der sich an Email, Kalender und Meeting Notes anbindet, daraus einen langlebigen Knowledge Graph aufbaut und diesen Kontext nutzt, um bei der täglichen Arbeit zu helfen – Meeting Prep, Email Drafts, Decks, Follow-ups. Alles lokal als plain Markdown, inspizierbar und editierbar.

Key Features:

• Knowledge Graph aus Arbeitsdaten: Gmail, Google Calendar, Meeting Notes (Fireflies) werden automatisch zu einem vernetzten Wissensgraph verarbeitet – Personen, Projekte, Entscheidungen, Commitments
• Langlebiger Kontext: Statt bei jeder Anfrage neu zu suchen, akkumuliert Wissen über Zeit – Beziehungen sind explizit und editierbar
• Artefakte generieren: Meeting Briefs, Email Drafts, PDF-Slides, Zusammenfassungen – alles auf Basis des aufgebauten Kontexts
• Live Notes: Notizen, die sich automatisch aktualisieren – Competitor Tracking, Deal Monitoring, Themen-Summaries über Web, X, Reddit und eigene Kommunikation
• Voice Memos: Sprachnotizen, die automatisch Key Takeaways in den Graph schreiben (via Deepgram/ElevenLabs)
• MCP Tools: Erweiterbar über MCP – Exa Search, Twitter, Slack, Linear, GitHub, Composio und eigene Tools
• Bring your own Model: Lokale Modelle (Ollama, LM Studio) oder hosted APIs – Modell jederzeit wechselbar
• Obsidian-kompatibel: Der Graph ist ein Vault aus Markdown mit Backlinks – funktioniert auch direkt in Obsidian

Desktop App für Mac, Windows, Linux. Will man das? Kommt drauf an, wie wohl man sich damit fühlt, dass ein AI-System dauerhaft die eigene Email und Kalender mitliest und verarbeitet. Local-first und Markdown-basiert sind die richtigen Designentscheidungen für Vertrauen – man kann jederzeit sehen und editieren, was Rowboat „weiß“. Für Leute, die ohnehin viel in Meetings und Email arbeiten und ständig Kontext rekonstruieren müssen, könnte das ein Game Changer sein. Die YC-Beteiligung und 14.7k Stars zeigen, dass der Markt das ähnlich sieht.

https://github.com/rowboatlabs/rowboat

Files.md – Dein Leben in Plain Markdown Files

Files.md ist eine minimalistische, local-first Notiz-App für .md-Dateien – Notes, Journal, Habits, Checklists und Tasks in einer PWA, die komplett im Browser läuft. Keine Daten verlassen das Gerät, kein Build-System, einfach index.html öffnen.

Key Features:

• Local-First: Dateien liegen auf dem eigenen Gerät (OPFS oder lokaler Ordner), nichts wird an einen Server gesendet
• Chat-Eingabe: Gedanken schnell per Chat-Interface abladen – wird automatisch in Chat.md gespeichert und über alle Geräte synchronisiert
• Vordefinierte Struktur: Notes, Journal, Habits, Checklists, Tasks, Archive – alles als plain .md, aber flexibel anpassbar
• Verlinkung: Notizen untereinander verlinken per [-Hotkey, Backlinks generierbar per Script
• Sync flexibel: iCloud/Dropbox/Google Drive (kein Server nötig), Self-Hosted mit einem einzigen Go-Binary, oder gehostet via app.files.md
• Telegram Bot: Notizen und Tasks unterwegs über den Bot erfassen
• LLM-friendly: Struktur als llms.txt verfügbar, kopierbar in CLAUDE.md/AGENTS.md – AI Agents verstehen die Dateistruktur direkt
• Zero Dependencies: Kein Build-System, keine Frameworks – in 10 Jahren web/index.html öffnen und es funktioniert

Die radikale Einfachheit ist gleichzeitig Stärke und Einschränkung. Wer von Obsidian-Plugin-Overload frustriert ist und eigentlich nur einen Ort für verlinkte Markdown-Notizen braucht, findet hier genau das – nicht mehr, nicht weniger. Dass der gesamte Codebase so klein ist, dass ein LLM ihn komplett erfassen und erweitern kann, ist ein cleverer Ansatz für die Zukunftssicherheit. Seit 5 Jahren wird das Projekt selbst aktiv vom Autor genutzt.

https://github.com/zakirullin/files.md

❓ 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: