Willkommen zu allesnurgecloud.com – Ausgabe #244

Tja, S&P Global hat das Rating von Oracle von BBB auf BBB- herabgesetzt, das ist noch ein Level über „Junk“. Als Begründung nennt S&P die enormen Investments in KI Infrastruktur (95 Milliarden) und ein Cashflow-Defizit von 42 Milliarden für das Geschäftsjahr 2027. Bei den anderen Hyperscalern ist S&P bisher noch gnädig, mal schauen, wann sich das ändert.

Für eure Endgeräte gibt es nun Bonsai 27B, ein von Qwen36 27B destilliertes Modell, welches je nach Variante nur 5,9GB oder sogar nur 3,9 GB an Speicherplatz benötigt. Da haben wir dann wirklich bald Jarvis in der Hosentasche dabei.

Und im November feiert die „Open Source Monitoring Conference“ in Nürnberg 20 Jahre OSMC. In diesem Jahr findet die Konferenz vom 17. bis 19.11.2026 statt und ich darf einen Talk zu „Open Source End2End Monitoring with Upright“ beisteuern. Sehen wir uns dort auf ein Kaltgetränk?

Am Freitag trafen sich die Remote Worker in Venice Beach für deren erstes „Remote Work Meetup“ – ein Video dazu hat die LA Times bei Instagram.

So, und nun viel Spaß mit der neuen Ausgabe!

Happy Bootstrapping Podcast

In der aktuellen Podcast Folge 181 habe ich mit Femke Bohling von THREE.E gesprochen. Nach fast zehn Jahren im ABOUT-YOU-Kosmos, zuletzt bei der Commerce-Plattform SCAYLE, hat sie mit ihren Mitgründerinnen eine bootstrapped E-Commerce-Agentur aufgebaut – Leitsatz: 95 Prozent im E-Commerce sind Execution, nicht Strategie. Wir reden über ihr Agenturmodell, warum THREE.E komplett auf KI umgestellt hat und wofür es Agenturen in der KI-Ära noch braucht. 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:

AWS-Billing-Bug zeigt Billionen-Rechnungen

Einige Kunden dürften am 17. Juli mit einem ordentlichen Schreck aufgewacht sein: In den Budget-Alerts standen plötzlich Beträge in Millionen-, Milliarden- und teils Billionenhöhe. Auf r/aws fragte ein Nutzer halb im Scherz, was man mit sieben Billionen Dollar Schulden anfange; ein Parallel-Thread lief mit ähnlichen Summen voll. Ursache war kein Hack, sondern ein Bug in AWS‘ Abrechnung: Seit dem 16. Juli, 19:38 PDT zeigte die Billing-Konsole falsche Schätzwerte an, laut AWS Health ausgelöst durch ein fehlerhaftes Unit Pricing im Subsystem für die geschätzten Kosten.

Betroffen waren ausschließlich die Estimates, keine echten Abbuchungen. AWS pausierte die Berechnung, rollte die fehlerhafte Änderung zurück und spielte korrigierte Daten per Backfill nach; vollständige Erholung wurde bis 19. Juli in Aussicht gestellt. Wer Cost and Usage Reports mit „Create new report versions“ fährt, muss allerdings selbst ran: Die Korrektur kommt unter neuer assemblyId, nachgelagerte Prozesse in Athena, Redshift oder QuickSight müssen darauf zeigen, sonst laufen sie mit falschen Zahlen weiter.

Der Schaden war real, nur nicht finanziell. Nutzer berichteten von Herzrasen und dem ersten Reflex, panisch Buckets und ganze Accounts zu löschen; ba-na-na- kommentierte trocken „Engineering team vibe coding the billing UI“. Am Ende bemühte der Thread den alten Bankerspruch: Schuldest du AWS 100 Dollar, ist das dein Problem; schuldest du Milliarden, ist es AWS‘ Problem.

Interessanter als der Bug ist die alte Wunde, die er wieder aufriss. Ein Nutzer verfasste noch im Thread einen Musterbrief an Verbraucherschützer, weil AWS bis heute nur passive Alerts bietet, aber keinen harten Ausgabendeckel. Genau diese fehlende Kill-Switch-Funktion hatte ich in Ausgabe #236 am echten 97.000-Dollar-Bedrock-Fall beschrieben – dort ging es um echtes Geld und einen kompromittierten Account, hier nur um einen Schrecken.

Ein sechsstelliger Alert um zwei Uhr nachts fühlt sich nach Ruin an, egal ob Bug oder nicht – die Hyperscaler kochen eben auch nur mit Wasser. Im nächsten Jahr sehen wir dann bestimmt die erste fehlerhafte Abbuchung als Kreditkarten-Alert….

AWS: Inaccurate Estimated Billing Data – $1.7 billion

---

Elasticsearch bekommt einen Columnar Mode

Was in Ausgabe 243 noch als Streit zwischen ClickHouse-Fans und Datadog-Zahlern lief, bekommt jetzt eine späte Bestätigung von unerwarteter Seite: Elastic erklärt im eigenen Blog, Elasticsearch werde „a first-class columnar database“. Der Columnar Mode — technische Preview in 9.5, GA in 9.6 — legt Daten nur einmal spaltenweise ab, ohne die redundante Dokumentkopie und ohne Indizes, die der Workload nicht braucht.

Der Kontext macht das interessant. Elasticsearch war jahrelang das Dokumentmodell schlechthin: jedes Feld mehrfach gespeichert — das Original, invertiert für die Suche, als doc values fürs Aggregieren. Bei reichen, niedrigvolumigen Dokumenten ein guter Deal; bei Milliarden einmal geschriebenen Logzeilen ein teurer. Genau der Punkt, an dem Elasticsearch laut Mat Duggans Rant bei 10 TB/Tag kapituliert.

Elastic dreht die Defaults um: kein paralleles Original, invertierte Indizes nur, wo sie sich lohnen, das Dokument bei Bedarf aus dem Spaltenspeicher rekonstruiert statt doppelt gehalten. Das Profil Columnar Logs behält den Index aufs message-Feld, die pure Variante lässt ihn auf String-Feldern fallen. Die Kompression liege laut Elastic bei 5–10x statt 1,5–3x, bei Low-Cardinality-Feldern bis 30x.

Elastic habe doc values seit 2013, aber stets als Sekundärstruktur über dem Dokumentmodell. Jetzt sei für einen wachsenden Datenanteil das Columnar die Wahrheit und das Dokument die Optimierung, die die meisten nicht bräuchten. Präzise das Argument, das Charity Majors zuletzt machte: Es geht nicht um einen Vendor, sondern um columnar storage als solches.

Der Rest — „the only major platform“, eine Engine für alles — bleibt üblicher Plattform-Anspruch. Substanziell ist die Konzession selbst: Der Incumbent baut nach, was die Herausforderer erzwungen haben. Migrierst du bei diesen Volumen schon, oder wartest du auf 9.6?

Why Elasticsearch is becoming a columnar database

---

---

Von SingleStore zu ClickHouse und PlanetScale

65 Milliarden Zeilen, ein Entwickler, drei Monate Deadline: Jack Ellis, CTO der Google-Analytics-Alternative Fathom, beschreibt in einem ausführlichen Blogpost, wie er Fathom V4 von der HTAP-Datenbank SingleStore auf ein geteiltes Setup migrierte — ClickHouse für OLAP, PlanetScale für OLTP, Redis für den Cache. Die Erkenntnis dahinter: Fathom hatte nie einen echten HTAP-Workload, OLTP und OLAP liefen ohnehin getrennt.

Der technische Kniff bei der Migration ist elegant. Statt der klassischen SingleStore-nach-S3-nach-ClickPipes-Route liest ClickHouse direkt per MySQL-Wire-Protokoll aus SingleStore, das MySQL-kompatibel ist — nach acht Iterationen des Migrationsskripts der Durchbruch, mit 700.000 bis 1 Million Zeilen/Sekunde. Performance kam dann nicht aus Materialized Views, sondern aus vorab aggregierten Rollup-Tabellen: Eine 6–8-Sekunden-Query fiel auf unter eine Sekunde.

Bemerkenswert offen ist Ellis beim Enabler: Erst Opus 4.5 und Cursor hätten das Projekt für ihn allein machbar gemacht — er gebe Struktur und Richtung vor, lese jede Zeile, schreibe den Code aber nicht mehr selbst.

Die Kostenrechnung, mit Ellis‘ eigenem Disclaimer, dass es kein 1:1-Vergleich sei:

• SingleStore (On-Demand): 23.126 $/Monat
• ClickHouse, PlanetScale und ElastiCache zusammen: 2.230 $/Monat

Dass SingleStore als HTAP-Spezialist dabei nicht schlecht wegkommt — Ellis lobt Support und Technik ausdrücklich — macht den Bericht glaubwürdiger als das übliche Migrations-Marketing. Noch in Ausgabe 132, als Ellis seine AWS-Rechnung um 100.000 $ drückte, lief Fathom zufrieden auf SingleStore; der Abschied fällt jetzt entsprechend versöhnlich aus. Betreibst du OLTP und OLAP noch in einer Datenbank, nur weil es bequem ist?

Two database migrations and a divorce

---

Cursor-Report: 40 % Commits ohne Review

Cursor hat zwei Jahre aggregierte Nutzungsdaten ausgewertet, Gergely Orosz ordnet sie im Pragmatic Engineer ein. Die Verteilung ist extrem: Der Median-Entwickler kommt auf rund 700 Zeilen Code pro Woche, das p90 auf 9.000, das oberste 1 Prozent auf 30.000 bis 40.000 – so viel wie 45 Median-Devs zusammen. Ob diese Power-User echten Mehrwert liefern oder nur 45-mal so viele Bugs, lässt der Report offen.

Aufschlussreicher ist die Token-Ökonomie. 90 Prozent der Tokens sind Input, also gelesene Codebase und Doku – das klassische 10:1-Verhältnis von Lesen zu Schreiben, das Robert C. Martin schon 2008 beschrieb, jetzt für Agenten. Rechnet man Caching ein, entfallen auf Output nur noch 0,6 Prozent; ohne Cache läge die Rechnung 10-mal höher.

Bei den Modellkosten bleibt Opus 4.7 das teuerste, laut Cursor rund 10-mal teurer pro Request als das hauseigene Composer 2.5 – eine Zahl mit Eigeninteresse, schließlich vergleicht Cursor sein eigenes Modell. Pro akzeptierter Zeile schrumpft der Abstand, weil Opus häufiger angenommen wird und damit gleichauf mit GPT-5.5 liegt.

Der eigentliche Aufreger steht am Schluss: Innerhalb eines Monats stieg der Anteil der Entwickler, die Agenten-Commits ohne manuelle Prüfung durchwinken, von 10 auf 40 Prozent – zeitgleich mit den Releases von Opus 4.7 und GPT-5.5. Mario Zechner hatte in Ausgabe #236 genau davor gewarnt: Ein Mensch kippt nicht in Stunden 20.000 ungeprüfte Zeilen in eine Codebase, ein Agentenschwarm schon.

The Pulse: Interesting AI coding stats from Cursor

---

Torvalds stellt sich hinter KI-Code-Review

Auf der Kernel-Mailingliste hat Linus Torvalds die Debatte über KI-gestütztes Code-Review kurzerhand beendet: Linux sei kein Anti-KI-Projekt, und wer damit ein Problem habe, könne den Kernel forken – „fork it. Or just walk away.“ Auslöser war der Vorschlag, das Patch-Management-System Patchwork mit Sashiko zu verkoppeln.

Sashiko ist ein agentisches Review-System von Google-Kernel-Entwickler Roman Gushchin, das unter dem Dach der Linux Foundation LKML-Einreichungen scannt und Patch-Feedback erzeugt. In eigenen Messungen findet es mit Gemini 3.1 Pro rund 53,6 Prozent der Bugs aus den letzten 1.000 Commits mit Fixes-Tag; die LLM-Kosten trägt Google. Die False-Positive-Rate liege laut Autoren im 20-Prozent-Bereich – ein Wert, den Maintainer wie Lorenzo Stoakes für zu optimistisch halten. Der konkrete Streit dreht sich um Laurent Pincharts Einwand: Sashikos Kommentare sollten erst von Maintainern geprüft werden, bevor sie automatisch an die Entwickler gehen.

Torvalds zieht die Grenze bei der Ideologie, nicht beim Werkzeug. KI sei nicht perfekt, aber wer auf ihre Fehler zeige, solle in den Spiegel schauen – auch natürliche Intelligenz sei nicht immer brillant. Entschieden werde nach technischem Merit, nicht aus weltanschaulichen Gründen. Gezwungen werde niemand, aber ein Veto gegen Kollegen, die KI nutzen wollen, lässt er nicht gelten.

Die eigentliche Frage stellt Torvalds selbst: LLM-Tools sollen Maintainer entlasten, nicht zusätzlich belasten. Ob das gelingt, ist offen – Jeff Geerling hatte in Ausgabe #224 beschrieben, wie KI-Slop dieselben Maintainer gerade unter Review-Last begräbt. Ein System, das echte Bugs findet, aber unerschöpflich neue Reviews produziert, sitzt genau auf dieser Kippe.

Linux Kernel Mailing Liste

---

PgBouncer über die Single-Core-Grenze skalieren

PgBouncer ist single-threaded — ein Prozess, ein Core, egal wie viele die Maschine hat. Auf einer 16-vCPU-Box erledigt also ein Kern das komplette Connection-Pooling, während fünfzehn Däumchen drehen. Kaushik Iska zeigt im Engineering-Blog von ClickHouse, wie ClickHouse Managed Postgres diese Wand umgeht: statt eines Prozesses eine ganze Flotte, dimensioniert nach den verfügbaren Cores.

Der Kern ist so_reuseport — alle Prozesse binden denselben Port, der Kernel verteilt eingehende Verbindungen, Clients sprechen weiter einen einzigen Endpoint an. Zwei Fallstricke löst ClickHouse dabei sauber. Query-Cancellation läuft über eine separate Verbindung mit Cancel-Key, die beim falschen Prozess landen kann, der die Query gar nicht kennt — dann passiert nichts. Über Peering kennen sich die Prozesse gegenseitig und leiten den Cancel an den richtigen weiter. Zusätzlich wird das Connection-Budget durch die Prozesszahl geteilt, damit die Flotte Postgres nicht übersubskribiert.

Der Benchmark auf identischen c7i.4xlarge-Instanzen ist deutlich, ein Prozess gegen sechzehn:

• Einzelprozess: Peak bei 87k tps, unter Last runter auf 77k bei 256 Clients — bei ~97% auf einem Kern, während die Box unter 10% bleibt.
• Flotte: rund 336k tps, also etwa 4x, verteilt auf ~8 Kerne.

Die Einordnung bleibt nüchtern: Ein einzelner PgBouncer sei ein solider Default, bis der Pooler statt Postgres zum Flaschenhals werde — erst dann lohne der Aufwand. Dass OpenAI PgBouncer laut Ausgabe 220 als „boring technology“ zum Drücken der Verbindungszeit einsetzt, zeigt, wie tragend dieses Stück Plumbing ist. Läuft bei dir noch ein einzelner Pooler-Prozess auf einer Multi-Core-Maschine?

How we scale PgBouncer in ClickHouse Managed Postgres

---

Warum Action Items das Incident Review dominieren

„Drei Meetings in einem Trenchcoat“ — so beschreibt Brent Chapman in seinem Blog das typische Post-Incident-Review. Was als eine Kalendereinladung firmiert, erledige in Wahrheit drei Aufgaben mit je eigener Teilnehmerliste und eigenem Modus:

• Das Arbeitstreffen, in dem die Beteiligten ihr Bild vom Hergang abgleichen und Lücken in der Timeline schließen.
• Die Action-Items-Runde, die benennt, was Aufmerksamkeit braucht — und noch keine Lösungen entwirft.
• Die Präsentation der Erkenntnisse für alle, die nicht dabei waren.

Die Kernbeobachtung: Werden die drei in eine Stunde gepresst, gewinnen die Action Items. Die Frage nach der Gegenmaßnahme fühle sich dringlicher an als die nach dem Lerneffekt, und sobald der erste Vorschlag für ein neues Monitoring falle, kippe die Runde vom Verstehen ins Lösen — und komme selten zurück. Das deckt sich mit Lorin Hochsteins Warnung aus Ausgabe 218, wonach der reflexhafte „let’s add an alert“-Ansatz nach Incidents bei größeren Ausfällen selbst zum Problem wird.

Der Zweck eines Reviews sei das Lernen — nicht Schuldzuweisung, nicht Action Items, nicht das Dokument für den Compliance-Ordner. Chapmans einfachster Schutz im kombinierten Meeting: die Action Items explizit auf die letzten fünfzehn Minuten vertagen, idealerweise sogar um 24 Stunden, damit das Verständnis erst reifen kann.

Sein Modell versteht er ausdrücklich als Diagnose, nicht als Vorschrift — die wenigsten Incidents brauchen drei Sitzungen. Der Vergleich zu NTSB-Untersuchungen und den M&M-Konferenzen in Kliniken sitzt trotzdem. Wie viele deiner Reviews sind eigentlich getarnte Action-Item-Runden?

The Post-Incident Review Meeting: three meetings in a trench coat

---

Amazon-CTO: Unternehmen wechseln zu Open-Source-KI

Dass Open-Source-KI billiger ist, überrascht niemanden — interessant ist, wer es inzwischen sagt. Auf dem UN-Gipfel „AI for Good“ in Genf erklärte Amazon-CTO Werner Vogels, Unternehmen wechselten angesichts steigender KI-Kosten zunehmend zu offenen Modellen; US-Regierungsbeschränkungen für proprietäre Releases beschleunigten den Trend zusätzlich.

Die Zahlen dahinter sind deutlich, wenn auch teils aus interessierter Quelle:

• Open-Source- und chinesische Modelle seien 60 bis 90 % günstiger als Spitzenmodelle von Anthropic und OpenAI (Justin Summerville, OpenRouter, via CNBC).
• Eine Citibank-Analyse nenne 18 Cent pro Million Token für chinesische Modelle gegenüber im Schnitt 4 Dollar für die besten proprietären.
• Alibabas Qwen knackte Anfang 2026 die Milliarde kumulativer Hugging-Face-Downloads, verdrängte Metas Llama und kam im Februar allein auf 153,6 Millionen — mehr als die nächsten acht Anbieter zusammen.

Beim Leistungsabstand ist Vorsicht angebracht: Chinesische Modelle lägen laut Kyle Chan (Brookings) nur noch sechs bis neun Monate hinter den US-Frontier-Systemen — eine Schätzung, kein Benchmark.

Den regulatorischen Kontext liefert Anthropic selbst: Das US-Handelsministerium zwang den Anbieter im Juni, Fable 5 und Mythos 5 aus Sicherheitsgründen offline zu nehmen — laut The Hill ein Nachfrage-Booster für offene Alternativen. Der Zugang ist seit dem 1. Juli wiederhergestellt, die Unsicherheit als Self-Hosting-Argument bleibt aber.

Rechnet sich der Wechsel zu offenen Modellen bei dir schon, oder zahlst du noch für die letzten Prozent Qualität?

Amazon-CTO sagt, Unternehmen wechseln zu günstigerer Open-Source-KI

---

Fünf Lehren aus sieben Monaten Vibe-Coding

„Wie das Em-Dash zum KI-Schreiben, so das God-Object zum KI-Coding“ — mit diesem Vergleich fasst der Entwickler hinter k10s in seinem Devlog sieben Monate Vibe-Coding zusammen. k10s ist ein GPU-fokussiertes Kubernetes-TUI (wie k9s, aber für NVIDIA-Cluster mit DCGM-Metriken), gebaut in 234 Commits über rund 30 Wochenenden, komplett mit Claude. Jetzt archiviert er die Go-Version und schreibt neu in Rust.

Der Bruch kam, als er nach der GPU-Fleet-View zurück auf die Pods-View wechselte — und nichts mehr renderte. Er las erstmals die gesamte model.go: 1.690 Zeilen, ein Struct für alles, eine Update()-Funktion mit 110 switch/case-Zweigen. Das God-Object hatte sich selbst gefressen.

Seine fünf Lehren, jeweils als Direktive für die CLAUDE.md gedacht:

• KI baut Features, keine Architektur — die Invarianten musst du selbst vorgeben.
• Das God-Object ist der Default; ohne View-Isolation kollidieren Keybindings (dasselbe s macht je nach View drei Dinge).
• Die Velocity-Illusion weitet den Scope: aus dem GPU-Tool wurde ein generischer k9s-Klon, weil jedes Feature „gratis“ wirkte.
• Positionsdaten als []string mit Magic-Indizes sind eine Zeitbombe — typisierte Structs statt Arrays.
• Die KI besitzt keine State-Transitions; Mutation aus Goroutine-Closures ergab eine Data-Race.

Der Wechsel zu Rust erfolge nicht, weil es besser sei, sondern weil er es steuern könne. Passend zum Fathom-Bericht weiter oben, wo Jack Ellis jede Zeile las und die Architektur selbst machte: Unendliches Zeilen-Budget heißt nicht unendliches Komplexitäts-Budget. Denselben Slop-Moment nach dem Durchlesen der eigenen Codebase beschrieb Mo Bitar in Ausgabe 221.

Schreibst du die Architektur noch selbst, bevor der Agent loslegt? Ich habe eigentlich gute Erfahrungen mit „engen Vorgaben“ und Boilerplates als Vorgabe und Guardrails gemacht.

Im going back to writing code by hand

---

Schmunzelecke

Ein Bekannter von mir dokumentiert seine Bewerbung bei Mistral hier ziemlich witzig und transparent – viel Erfolg bei Staffel 2!

Jemand hat sich hier die Mühe gemacht, alle in Jurassic Park verwendeten Computer zu analysieren und zu dokumentieren – nerdy, aber sehr cool.

---

💡 Link Tipps aus der Open Source Welt

Meetily – Privacy-First AI Meeting Assistant, komplett lokal

Meetily ist ein Open-Source-Meeting-Assistant, der Meetings aufnimmt, in Echtzeit transkribiert und per AI zusammenfasst – alles lokal auf dem eigenen Rechner, ohne dass Daten die Maschine verlassen. Gebaut mit Tauri und Rust.

Key Features:

• Lokale Echtzeit-Transkription: Whisper oder Parakeet Modelle, kein Cloud-Service nötig. GPU-Beschleunigung auf Apple Silicon (Metal/CoreML), NVIDIA (CUDA) und AMD/Intel (Vulkan)
• AI Summaries: Zusammenfassungen via Ollama (lokal empfohlen), Claude, Groq, OpenRouter oder eigenem OpenAI-kompatiblen Endpoint
• Import & Enhance: Bestehende Audio-Dateien importieren und mit anderem Modell oder anderer Sprache neu transkribieren
• Audio Mixing: Mikrofon und System-Audio gleichzeitig aufnehmen mit intelligentem Ducking und Clipping Prevention
• Custom Endpoint Support: Eigene OpenAI-kompatible Infrastruktur für Summaries anbinden
• Cross-Platform: macOS, Windows, Linux – Installer oder Build from Source

Im Vergleich zum ebenfalls vorgestellten Handy (reine Speech-to-Text App) und Vosk (API/Toolkit) ist Meetily ein kompletter Meeting-Workflow: Aufnahme → Transkription → Zusammenfassung in einer App. Pro-Version mit Speaker-Diarization, Custom-Templates und Team-Features separat erhältlich.

Tech Stack: Rust Backend (Tauri), Next.js Frontend, Whisper.cpp/Parakeet für STT.

Für alle, die einen lokalen Meeting-Assistenten suchen, ohne Otter.ai oder Fireflies ihre Gesprächsdaten anzuvertrauen, ist Meetily aktuell die ausgereifteste Open-Source-Option. Die GPU-Beschleunigung macht Echtzeit-Transkription auf moderner Hardware praktikabel, und die flexible AI-Provider-Wahl für Summaries gibt die Kontrolle über den gesamten Stack.

https://github.com/Zackriya-Solutions/meetily

PatchMon – Linux Patch Management & Automation Plattform

PatchMon gibt Ops-Teams ein Single Pane of Glass für Monitoring, Patching und Absicherung ihrer Linux-Flotte – mit leichtgewichtigem Agent, der ausschließlich ausgehend kommuniziert. Kein SSH-Exposure, keine eingehenden Firewall-Regeln, kein VPN nötig.

Key Features:

• Outbound-Only Agent: Agent initiiert alle Verbindungen zum Server, keine eingehenden Ports auf Zielhosts. Unterstützt Linux (apt, dnf, yum, apk, pacman), FreeBSD (pkg) und Windows
• Dry-Run & Approve: Patch-Transaktion vorab simulieren, reviewen und per One-Click freigeben – mit Audit Trail wer was wann approved hat
• Live Patch Streaming: Patch-Ausführung in Echtzeit im Browser verfolgen via WebSocket, mit Abort-Möglichkeit
• Compliance Scanning: OpenSCAP CIS Benchmarks und Docker Bench for Security mit Score-Tracking über Zeit
• Web SSH Terminal: Browser-basierter SSH-Zugang zu jedem Host, optional über Agent geroutet (kein SSH-Port-Exposure)
• AI Terminal Assistant: Eingebauter AI Chat im SSH Terminal für Command Suggestions und Error Diagnosis (OpenRouter, Anthropic, OpenAI, Gemini)
• Docker Monitoring: Automatische Discovery von Containern, Images, Volumes mit Echtzeit-Status
• RBAC & OIDC SSO: Granulare Permissions, Authentik/Keycloak/Okta Support mit Auto-Provisioning

Single Binary: Go Backend mit eingebettetem React Frontend, PostgreSQL + Redis. Deployment via Docker oder Proxmox LXC per One-Liner. Cloud-Variante verfügbar.

Für Ops-Teams, die bisher Ansible-Playbooks, Cron-Jobs und SSH-Tunnel für Patch Management zusammenkleben, ist PatchMon ein deutliches Upgrade. Der Outbound-Only-Agent löst das größte Deployment-Problem – man muss keine Firewall-Regeln auf Zielhosts anfassen. Die Dry-Run → Approve → Execute Pipeline mit Live-Streaming gibt Kontrolle, die man bei den meisten Patch-Tools vermisst.

https://github.com/PatchMon/PatchMon

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