Willkommen zu allesnurgecloud.com – Ausgabe #223
Die KI News werden immer verrückter – erstmal sichert sich Anthropic 30 Milliarden Dollar in einer neuen Finanzierungsrunde und ist nun mit 380 Milliarden Dollar bewertet. Mistral AI aus Frankreich hat angekündigt, 1,2 Milliarden Dollar in „digitale Infrastruktur“ und Rechenzentren in Schweden zu investieren. Verrückt.
Bei den ganzen OpenClaw News komme ich ja auch selber fast nicht mehr mit – ein Thema hat es aber in die Schmunzelecke geschafft.
So, nochmal durchschnaufen und dann geht es los mit einer prall gefüllten Ausgabe hier.
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 159 spreche ich mit Alex Schäfer vom YouTube Kanal „CarRanger“. Die Kollegen der Schwarz Gruppe kennen den Alex vielleicht – andere kennen ihn von YouTube? Da hat er mittlerweile 229.000 Abonnenten und macht das Ganze seit dem Herbst 2025 in Vollzeit. Wir sprechen in der Folge darüber, wie das „Auto-YouTube-Game“ so funktioniert, wieviel Zeit er für ein Video benötigt, wieviel man mit älteren Videos verdient und der Kanal überhaupt wächst – Die Folge gibt es deshalb auch bei YouTube und vermutlich alle Folgenden auch (Folge bei Spotify/Apple).
Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).
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.
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:
Hyperscaler-Earnings: Google Cloud überholt mit 48% Wachstum
Die Hyperscaler haben ihre Quartalszahlen vorgelegt – und alle drei investieren so aggressiv in Datacenter wie nie zuvor. Der Doppelgänger-Podcast hat die Zahlen von Google Cloud, AWS und Microsoft Azure verglichen.
Google Cloud überrascht mit 48% Wachstum – eine Beschleunigung von 28% Anfang des Jahres über 32% und 33,5% auf nun fast 50%. Die Cloud-Sparte hat sich von einer defizitären Einheit zur Cash-Cow entwickelt: Vor vier Jahren lag die operative Marge bei minus 16%, jetzt bei rund 30% – fast auf AWS-Niveau. Bei einer Umsatz-Runrate von 73 Milliarden Dollar wirft Google Cloud etwa 20 Milliarden operativen Gewinn pro Jahr ab.
Microsoft Azure wächst mit 39% (währungsbereinigt 38%) – eine minimale Verlangsamung gegenüber den 40% im Vorquartal, was den Markt enttäuschte. Die Aktie verlor zwischenzeitlich 12%. Pikant: 45% der zukünftigen Cloud-Umsätze stammen laut den Doppelgängern allein von OpenAI – ein erhebliches Klumpenrisiko. Die Gesamtmarge sank von 49% auf 47%, weil Microsoft massiv in eigene KI-Forschung investiert statt die Kapazitäten an Kunden zu vermieten.
AWS bleibt Marktführer mit einer Umsatz-Runrate von 140 Milliarden Dollar und beschleunigt das Wachstum von 17,5% über 20% auf nun 24%. Die operative Marge liegt stabil bei 35%. Amazons Cloud-Sparte generiert rund 50 Milliarden Dollar operativen Gewinn pro Jahr.
Die geplanten Datacenter-Investitionen für 2026 sind einfach nur crazy:
- Amazon: 200 Milliarden Dollar (mehr als der operative Cashflow von ~140 Mrd., erfordert Verschuldung)
- Google/Alphabet: 185 Milliarden Dollar (~100% des Operating Cashflow, aus eigener Kraft finanzierbar)
- Microsoft: ~120 Milliarden Dollar Runrate (85% des Operating Cashflow, +89% gegenüber Vorjahr)
Pips Fazit zu den aggressiven Investitionen: Bei einem Geschäft mit 35% operativer Marge sei es nicht dumm, weiter reinzuinvestieren. Der Markt sah das anders – trotz guter Ergebnisse fielen sowohl Amazon als auch Google nach den Earnings. Microsoft verlor zwischenzeitlich 350 Milliarden an Börsenwert, was Pip für übertrieben hält.
Die Microsoft Zahlen kamen eine Woche vor Google und AWS – daher findest du Microsoft in Folge 532 und die anderen beiden in der Folge 534.
Claude Code, but for Management
Fraunhofer-Studie: Homeoffice-Kipp-Punkt liegt bei 60 Prozent
Das Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO) hat gemeinsam mit der Techniker Krankenkasse eine umfassende Studie zur Produktivität im Homeoffice veröffentlicht. Die Datenbasis: Neben Produktivitätsdaten flossen drei unternehmensweite Befragungen ein, an denen zwischen 6.328 und 7.428 der rund 11.000 TK-Mitarbeitenden teilnahmen – eine Beteiligungsquote von 51 bis 59 Prozent.
Gemessen wurde die „Arbeitslast“ über die Einzelplatzauswertung (EPAW): bearbeitete Kundenanliegen und geführte Telefonate pro Zeiteinheit, getrennt nach Arbeitsort. Das Kernergebnis: Im Homeoffice erledigten die Mitarbeitenden im Schnitt etwa 20 Prozent mehr als im Büro. 68 Prozent gaben an, zu Hause konzentrierter zu arbeiten, 77 Prozent konnten Privatleben und Beruf besser vereinbaren.
Die Studie identifiziert allerdings einen „Kipp-Punkt“ bei etwa 60 Prozent Homeoffice-Anteil. Bis dahin steigt die Produktivität mit dem Remote-Anteil. Ab 60 Prozent verschwindet der Effekt. Bei Dienststellen mit unbegrenztem Homeoffice kehrt sich der Trend sogar um: Mehr Homeoffice führt zu weniger Output.
Interessant ist die Persona-Analyse: Die „Präsenzorientierten“ (48 Prozent) verorten sozialen Austausch primär im Büro. Die „Hybriden“ (24 Prozent) tauschen sich an beiden Orten gleichermaßen aus. Die „Virtuellen“ (18 Prozent) sehen keinen Mehrwert in physischer Präsenz.
Ein überraschender Einflussfaktor: Die Pendelzeit verzerrt das Werturteil erheblich. Bei unter einer Stunde Arbeitsweg empfinden 30 Prozent die Bürozeit als „sehr wertvoll“, bei über drei Stunden nur 6 Prozent. Führungskräfte bewerten Präsenz durchweg positiver.
Die Einschränkung ist wichtig: Der 60-Prozent-Wert gilt nur für die TK als Gesamtunternehmen. Einzelne Abteilungen hätten andere Kipp-Punkte – abhängig von Aufgaben und vorhandenem „Sozialkapital“. Die TK hat bereits reagiert: Ab 2026 wird statt maximal 60 Prozent Homeoffice nun mindestens 40 Prozent Büropräsenz definiert.
Ist sicherlich auch speziell, was hier gearbeitet und bewertet ist – trotzdem eine große Datenbasis, das kann ich als Remote Fan sicherlich nicht leugnen.
Anzeige
„Die Braut in der Cloud mit KRUU und „We Manage“
Mit unserem Kunden KRUU und dem Cloud-Anbieter Gridscale haben wir eine ausführliche Case Study veröffentlicht (PDF Version).
Die Case Study beschreibt unseren ganzheitlichen Ansatz einer „Rundum-sorglos-Betreuung“ mit einem maßgeschneiderten Angebot und Unterstützung bei DevOps- und SRE Herausforderungen.
Benötigst du auch Hilfe im Bereich „DevOps“, individuelle Managed Server oder ein Backup für dein 1-Personen DevOps Team oder Fullstack-Developer? Dann lerne uns jetzt kennen.
Oxide Computer: 200 Millionen Dollar Series C
Oxide Computer hat eine 200 Millionen Dollar Series C Finanzierungsrunde abgeschlossen – und ja, das darf man doppelt lesen: Erst im August 2025 hatte ich über die 100 Millionen Dollar Series B berichtet. Innerhalb weniger Monate hat sich das Gesamtkapital damit noch einmal verdoppelt.
Die Gründer Bryan Cantrill (der hier von der letzten Ausgabe) und Steve Tuck adressieren die naheliegende Frage direkt: Warum Geld einsammeln, wenn man es nicht braucht? Oxide hat echten Product-Market-Fit erreicht – ein physisches Produkt, das Kunden kaufen wollen, mit funktionierender Unit Economics. Das Kapital war also nicht notwendig, um das Geschäft am Laufen zu halten.
Die Erklärung ist eine andere: Die bestehenden Investoren wollten unbedingt nachlegen. Die Series C kommt ausschließlich von Bestandsinvestoren – denselben, die schon früh das Risiko mitgetragen haben. Für Oxide bot das eine strategische Chance: Mit dieser Finanzierung sei „Kapital als Risikofaktor komplett eliminiert“, schreiben die Gründer.
Das ist besonders relevant für Enterprise-Kunden. Wer Infrastruktur kauft, wurde schon oft von vielversprechenden Startups enttäuscht, die dann von etablierten Playern geschluckt wurden. „How do I know you won’t be bought?“ – diese Frage hören die Oxide-Gründer regelmäßig. Die Antwort jetzt: Oxide hat das Kapital, um auf unbestimmte Zeit unabhängig zu bleiben.
Die Vision aus dem ursprünglichen Pitch Deck von 2019 bleibt aktuell: Die größte Herausforderung war immer Zeit – und damit Kapital. Sechs Jahre später sehen die Gründer das bestätigt: Die technischen Hürden waren real, aber lösbar. Den Markt gab es tatsächlich. Die Series C sichert nun die langfristige Mission: „Kick butt, have fun, not cheat, love our customers — and change computing forever.“
Ist sicherlich gar nicht so einfach, sich in den Markt der „alteingesessenen“ Hardware Giganten einzunisten, bin aber überzeugt, dass die bei Oxide das schaffen.
Vela: simplyblock forkt Supabase für echtes Self-Hosting
Das Team von simplyblock hat Vela als Open Source veröffentlicht – einen Fork von Supabase, der auf echtes Self-Hosting ausgelegt ist. Der Grund: Supabase und Neon sind fundamentally SaaS-first, und wer versucht, sie selbst zu betreiben, stößt schnell auf „YAML-shaped sadness“.
Die Zahlen sprechen für sich: 350.000 Zeilen SaaS-spezifischer Code wurden entfernt (von 1,4 Millionen), 200.000 Zeilen neu geschrieben, 67.000 modifiziert. Weg sind Tracking, Payment-Systeme, gehardcodete Hostnames und Cloud-Provider-Annahmen.
Der technische Kern ist bemerkenswert: Vela behandelt Storage als First-Class-Dependency, nicht als Implementierungsdetail. Branches sind echte, isolierte Postgres-Instanzen in eigenen VMs – nicht nur weitere Datenbanken im selben Prozess. Clones sind Metadaten-Operationen auf Storage-Level-Snapshots, Blöcke werden geteilt bis sie divergieren. Boot-Zeit: 10 Sekunden statt Minuten.
Unter der Haube: Neons Autoscaling-Projekt für VM-Orchestrierung (mit geplanten Upstream-Contributions), VelaOS als minimales Buildroot-basiertes Betriebssystem, Keycloak statt GoTrue für Enterprise-taugliche Identity-Verwaltung, Loki statt Logflare für Logging. Extensions wie pgvector, pg_duckdb, PostGIS und TimescaleDB sind vorinstalliert.
Vela ist noch nicht fertig – HA, Read Replicas und Snapshot-basiertes PITR werden aktiv entwickelt. Eine öffentliche Sandbox unter demo.vela.run ermöglicht direktes Testen.
Christoph Engelbert von simplyblock schreibt auf LinkedIn: „Forking isn’t a betrayal. It’s how open source evolves when constraints change.“ Was würde eine serverless Postgres-Plattform aussehen, wenn man sie auf eigenen Servern betreibt? Vela ist zumindest ihre Antwort.
Bin mir jetzt nicht sicher, ob ich heute bsp. noch Keycloak da rein basteln würde, aber man hat sich sicher einige andere Lösungen angeschaut und sich dann trotzdem dafür entschieden. Bin gespannt.
We Forked Supabase Because Self-Hosted Postgres Is Broken.
Ein Blick hinter die Kulissen von AWS S3
Gergely Orosz hat Mai-Lan Tomsen Bukovec interviewt, VP of Data and Analytics bei AWS und seit über einem Jahrzehnt verantwortlich für S3. Die Zahlen sind beeindruckend: Hunderte Millionen Transaktionen pro Sekunde, über 500 Billionen Objekte, Hunderte Exabytes an Daten. Würde man alle Festplatten von S3 aufeinanderstapeln, reichten sie bis zur ISS – und fast wieder zurück.
Einige technische Highlights: Der Rollout von Strong Consistency war ein Engineering-Kraftakt. S3 startete 2006 mit Eventual Consistency, aber das Team schaffte es später, Strong Consistency einzuführen – ohne Kompromisse bei Availability oder höhere Kosten für Kunden. Schlüssel war ein Replicated Journal, bei dem Nodes verkettet sind und Writes sequentiell durchfließen.
S3 hat fast jeden performance-kritischen Code auf Rust umgeschrieben. Der Fokus: maximale Performance, minimale Latenz. Außerdem nutzt S3 Formal Methods produktiv – beim Check-in von Code für das Index-Subsystem laufen automatisch formale Beweise, die verifizieren, dass das Consistency-Modell nicht regressiert. „At a certain scale, math has to save you.“
Die 11 Nines Durability (99,999999999%) sind nicht nur versprochen, sondern gemessen. Auditor-Microservices inspizieren kontinuierlich jedes Byte. Bei Anzeichen von Problemen greifen automatische Repair-Systeme. Das Team kann jederzeit beantworten: „What is our actual durability this week?“
Interessant auch: S3 besteht aus rund 200 Services – deutlich weniger als Ubers 4.500+. Ein Designprinzip: „Scale must be to your advantage“ – Systeme müssen so gebaut sein, dass mehr Scale die Zuverlässigkeit verbessert, nicht verschlechtert
The Missing GitHub Status Page
GitHub hatte in den letzten Wochen erhebliche Stabilitätsprobleme – und wer am Montag versucht hat zu arbeiten, hat das vermutlich gemerkt. Die offizielle Status-Seite zeigt allerdings nicht das vollständige Bild.
Genau hier setzt „The Missing GitHub Status Page“ an. Die Macher erklären ihr Projekt mit einem Seitenhieb: „GitHub stopped updating its status page with aggregate uptime numbers some time ago — if you use it regularly, you might have a feeling why.“ Die inoffizielle Status-Seite rekonstruiert die tatsächliche Verfügbarkeit aus archivierten Status-Updates und berechnet Downtime auf Minuten-Ebene.
Die Zahlen sind ernüchternd: 91,95% Uptime in den letzten 90 Tagen – mit 72 Incidents. Der Februar 2026 sticht besonders heraus mit nur 83,13% Uptime. Zum Vergleich: Dezember und Januar lagen bei jeweils rund 94,5%.
Die einzelnen Services variieren stark: Copilot kommt nur auf 96,65% Uptime, Actions auf 98,21%. Selbst Git Operations – das Kerngeschäft – liegt bei 99,57%. Allein am 9. Februar gab es acht separate Incidents, darunter mehrere Major-Events bei Pull Requests, Issues und Git Operations.
Die Pipeline der alternativen StatusPage rekonstruiert die Historie, indem sie Atom-Feed-Snapshots via Flat Data abspielt und Incident-Timelines neu berechnet. Fehlende Komponenten-Tags werden mit GLiNER2 inferiert – aber nur, wenn sie explizit im Incident-Text verankert sind.
Für Teams, die auf GitHub Actions, Copilot oder Codespaces setzen, lohnt sich ein Blick auf diese alternative Sicht der Dinge.
The Missing GitHub Status Page
Claude Code für Management
Lee Bryant von Shift*Academy zieht eine interessante Parallele: Wenn Claude Code gut genug ist, dass Entwickler nicht mehr manuell coden müssen – warum schaffen wir Ähnliches nicht für Management und Prozessarbeit?
Die Antwort liege im Kontext. Saboo Shubham von Google bringt es auf den Punkt: „The models are commoditizing. Prices are dropping. Capabilities are converging.“ Der echte Wettbewerbsvorteil kommt nicht vom Modell, sondern davon, Wissen zu externalisieren und strukturiert an Agenten zu übergeben. Für Führungskräfte bedeutet das: Dinge aufschreiben, Value Chains dokumentieren, Prozesse beschreiben.
Antony Mayfield vergleicht Businesspläne mit Software: „Like novels, business plans are not completed; they are abandoned.“ Ein Knowledge-Engineering-Ansatz würde helfen – Pläne wie Betriebssysteme behandeln, die Bugs haben und gefixt werden müssen, mit Merge-Prozessen für verschiedene Stakeholder.
Rudy Kuhn von Celonis argumentiert, dass fehlende Composability in Enterprise-Prozessarchitekturen die Nutzung von AI blockiert. Prozesse müssen adressierbar und komponierbar sein, bevor sie programmierbar werden können.
Bryant sieht auch Potenzial in Small Language Models (SLMs): günstiger, zuverlässiger, weniger Halluzinationen, weil sie auf eng begrenzte Wissensdomänen fokussiert sind. Ein „Semantic Router“ als Governance-Layer könnte multiple spezialisierte kleine Agenten orchestrieren.
Die provokante Frage am Ende: Wenn Führungskräfte nicht in der Lage sind, ihre Organisation zu dokumentieren und Klarheit zu schaffen – brauchen wir dann vielleicht neue Rollen für menschliche Leader? „Maybe management shouldn’t be about work distribution anymore. Maybe it should focus on coaching, support, development.“
Claude Code, but for Management
Datadog Bits AI SRE: Incident-Investigation automatisiert
Datadog hat Details zu Bits AI SRE veröffentlicht – einem AI-Agenten, der Incidents automatisch untersucht und Root-Cause-Analysen in Minuten liefert. Laut Datadog reduzieren Teams damit ihre Time-to-Resolution um bis zu 95%.
Der entscheidende Unterschied zu frühen Ansätzen: Bits AI SRE ist kein Zusammenfassungs-Engine, der einfach alle verfügbaren Telemetriedaten in ein LLM kippt. Stattdessen arbeitet er wie ein menschliches SRE-Team: Hypothesen formulieren, mit gezielten Queries gegen Live-Daten testen, vielversprechende Spuren verfolgen, verwerfen was nicht passt.
Frühere Versionen machten mehr Tool-Calls und ließen ein LLM die Ergebnisse zusammenfassen. Problem: Mehr Daten bedeutete mehr Rauschen. In einem Beispiel-Incident war Kafka-Lag durch einen Spike in Commit-Latency verursacht – aber weil andere Tool-Responses „verdächtige“ Signale wie kritische Errors in einem Upstream-Service enthielten, landete das frühe Modell bei der falschen Root Cause.
Der Agent generiert Hypothesen, bricht komplexe Hypothesen in Sub-Hypothesen auf, und gräbt tiefer wenn Evidenz sie stützt. In einem CrashLoopBackOff-Incident fand die frühere Version „Pod ran out of memory“. Die neue Version grub eine Ebene tiefer: OOMs wurden durch einen Influx abnormal großer Payloads verursacht.
Datadog betont, dass ihr Benchmark auf echten, gelabelten Incidents basiert – mit dem „größten Dataset an Production-Telemetrie in der Industrie“. Das ist der entscheidende Vorteil: Wer die besten Trainingsdaten hat, baut den besten Agenten. Datadog scheint eine Menge Daten zu bekommen.
Na, sind die SRE Beschäftigten dann bald arbyteslos? Kann ich mir aktuell irgendwie noch kaum vorstellen.
How we built an AI SRE agent that investigates like a team of engineers
Entire: Ex-GitHub-CEO Dohmke sammelt 60 Millionen für Agenten-first-Plattform
Thomas Dohmke, bis August 2024 CEO von GitHub, hat sein neues Startup vorgestellt: Entire sammelt 60 Millionen Dollar in einer Seed-Runde bei einer Bewertung von 300 Millionen Dollar ein.
Die Investorenliste ist prominent: Felicis führt an, unterstützt von Madrona, Microsofts M12, den Samwer-Brüdern, Y-Combinator-Chef Garry Tan, Datadog-Gründer Olivier Pomel und Yahoo-Mitgründer Jerry Yang.
Die These: Bisherige Entwicklerplattformen seien für Mensch-zu-Mensch-Kollaboration gebaut. „Wir leben in einem Agenten-Boom“, sagt Dohmke. „Agenten können massive Mengen an Code schneller generieren, als das ein Mensch nachvollziehen könnte.“
Entire soll drei Ebenen bieten: Eine Datenbank für Code und Agenten-Kontext, eine semantische Ebene für institutionelles Wissen, und eine KI-basierte Benutzeroberfläche. Zum Start gibt es bereits „Checkpoints“ als Open-Source-Projekt – es erfasst automatisch den Kontext von KI-Agenten wie Claude Code oder Gemini CLI und speichert ihn in Git-Repositories.
Für europäische Kunden relevant: Die Plattform soll dezentral funktionieren. Ein Drittel des 15-köpfigen Teams sitzt in der EU, Dohmke pendelt zwischen Seattle und Stuttgart.
Mit GitHub wolle er nicht konkurrieren: „GitHub dient 180 Millionen Entwicklern mit bestehenden Prozessen. Wir bauen für eine neue Welt, in der Agenten die Mehrheit des Codes schreiben.“
Ex-Github-Chef sammelt 60 Millionen Dollar für Entwickler-Plattform
Schmunzelecke
Der GitHub User aka OpenClaw Bot @crabby-rathbun hat im matplotlib Projekt einen PR zur Verbesserung der Performance aufgemacht, welcher dann aus diversen Gründen abgelehnt wurde – unter anderem wegen der AI Policy des Projekts.
Der Bot hat sich das nicht gefallen lassen und dann einen Public Shaming Blog Artikel über den Projekt Maintainer erstellt – und dann später einen erneuten Artikel erstellt, bei dem er sich mit „lessons learned“ entschuldigt hat.
Sachen gibt’s.
💡 Link Tipps aus der Open Source Welt
Strix – Autonomous AI Security Testing Agents
Strix ist ein Open-Source AI Agent Framework für automatisierte Application Security Testing und Penetration Testing. Anders als statische Analyse-Tools führen die autonomen Agents Code dynamisch aus, validieren Vulnerabilities durch echte Proof-of-Concepts und arbeiten in Teams zusammen – mit kompletter Hacker-Toolkit-Ausstattung und ohne False Positives.
Features:
- Agentic Security Tools – HTTP Proxy, Browser Automation, Terminal, Python Runtime
- Real Validation – PoCs statt False Positives, dynamische Code-Ausführung
- Graph of Agents – Multi-Agent Orchestration mit Distributed Workflows
- Comprehensive Detection – IDOR, SQLi, XSS, SSRF, XXE, Auth Bypass, Business Logic Flaws
- Developer-First CLI – Actionable Reports mit Auto-Fix Suggestions
- Headless Mode – Non-interactive für CI/CD und Server-Automation
- GitHub Actions Integration – Security Scans auf Pull Requests
- Multi-Target Support – Local Codebase, GitHub Repos, Deployed Apps
- Incremental Persistence – Fortschritt wird gespeichert und kann fortgesetzt werden
Supported LLMs:
- OpenAI GPT-5 (Recommended)
- Anthropic Claude Sonnet 4.5
- Google Gemini 3 Pro Preview
- Vertex AI, Bedrock, Azure, Local Models (Ollama, LMStudio)
Strix revolutioniert Application Security Testing durch Agent-Autonomie. Während Tools wie Nuclei oder Burp Suite manuelle Orchestrierung brauchen, arbeiten Strix-Agents selbstständig zusammen, teilen Discoveries und validieren Findings dynamisch. Die CI/CD-Integration macht Security Testing zum First-Class-Citizen im Development Workflow. 20k GitHub Stars – cool!
Ich kannte das bisher nicht – spiele nun mal damit rum – kennst du es oder hast damit Erfahrung?
https://github.com/usestrix/strix
KSwitch – Native macOS Kubernetes Context Manager
KSwitch ist eine native macOS-App von Stefan Prodan (Flux Maintainer) für Kubernetes Context Management und GitOps Monitoring direkt aus der Menu Bar. Das in Swift geschriebene Tool bietet Quick Context Switching, Cluster Health Monitoring, Flux Operator Integration und einen integrierten Task Runner für Shell-Script-Automation – alles code-signed und notarisiert.
Features:
- Quick Context Switching – Kontextwechsel direkt aus der Menu Bar
- Cluster Status – Kubernetes Version, Node Health, Cluster Capacity (CPU/Memory/Pods)
- GitOps Monitoring – Flux Operator Version, Sync Status, Reconciler Health
- Organization – Favorites, Hidden Clusters, Custom Names und Colors
- macOS Notifications – Alerts bei Cluster Degradation oder Flux Failures
- Task Runner – Shell Scripts mit Input Parameters und Real-time ANSI Output
- Auto-Update – Selbst-Update via GitHub Releases
- Multi-Kubeconfig – Support für mehrere Files via
:Delimiter
KSwitch ist die native macOS-Antwort auf kubectx/kubens – aber mit deutlich mehr Features. Die Flux-Integration ist konsequent (nicht überraschend von einem Flux-Maintainer) und macht das Tool für GitOps-Teams besonders wertvoll. Der Task Runner mit ANSI-Output-Support hebt KSwitch von simplen Context-Switchern ab
https://github.com/stefanprodan/kswitch
❓ 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: