Willkommen zu allesnurgecloud.com – Ausgabe #239

So, frisch zurück vom Urlaub mit einer prall gefüllten Ausgabe – aktuell habe ich auch wieder Slots für Werbung im Newsletter frei – falls du eine Anzeige für ein Produkt, Dienstleistung oder ein Stellengesuch schalten möchtest, antworte mir einfach per Mail. Der Newsletter erreicht mittlerweile über 2000 IT Arbeitende direkt per Mail, LinkedIn und per RSS Feed.

Anscheinend ist die Börse und die IT zum SpaceX Börsengang nicht hopsgegangen – ich habe mir das entspannt von der Seitenlinie angeschaut. Schon ziemlich verrückt, was hier alles abgeht. Dann kommen noch Anthropic und OpenAI mit dem Börsengang dieses Jahr.

Ansonsten ist der Vortrag von Eugen und mir von der Rack & Stack Konferenz von Golem mittlerweile online bei YouTube – schau gerne mal rein, freue mich auf Fragen und Feedback zum Thema.

Und wie du schon weißt, baue ich aktuell mit Statuswerk eine komplett in Deutschland betriebene Statuspage – alle Daten, E-Mail und SMS bleiben hierzulande. Fokus nur darauf, dafür richtig und fair bepreist. Auf die Warteliste eintragen – Launch Ende Juni mit Early-Bird.

So, und nun viel Spaß mit der neuen Ausgabe

Happy Bootstrapping Podcast

In der aktuellen Podcast Folge 176 habe ich mit Henrik Roth von HappySupport gesprochen. Mit Mitgründer Niklas Gysinn baut er ein Hilfe-Center, das sich über die Codebase selbst aktuell hält. Wir reden über seine dritte Gründung nach neuroflash, den Pre-Seed über 200.000 Euro und warum sein erster Kunde über eine KI kam. Gerne kannst du die Folge auf YouTube schauen oder wie immer bei Spotify, Apple und allen anderen Playern anhören.

In Folge 175 von letzter Woche habe ich mit Katia Lübbert von Memovida über Festpreis-Bestattungen, 99 Prozent Akquise über SEO und SEA und ihren Quereinstieg aus dem PayPal-Konzern gesprochen – hier zur Folge.

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:

Supabase $500M, Multigres Alpha, OpenRouter Funding

Das Kapital fließt weiter in die Schichten unter den KI-Apps, und gleich zwei Runden derselben Woche zeigen, wohin: Supabase hat eine $500M Series F bei einer Pre-Money-Bewertung von 10 Milliarden Dollar eingesammelt, angeführt von GIC, mit Stripe als Zweitinvestor. Damit hat sich die Bewertung seit der Series E im Oktober erneut verdoppelt – die Spirale aus Ausgabe 206 dreht sich munter weiter. Treiber laut CEO Paul Copplestone: 600% mehr Datenbank-Launches im letzten Jahr, über 60% davon angelegt von irgendeinem KI-Tool, beschleunigt durch Claude Code und Codex. Bei knapp 10 Millionen Entwicklern bleibt die Frage, wie viel davon nach dem Vibe-Coding-Hype produktiv übrig bleibt.

Technisch interessanter ist das parallel von Sugu Sougoumarane vorgestellte Multigres v0.1 Alpha: ein open-source Kubernetes-Operator, der Postgres als „scalable operating system“ bündelt – Connection Pooling, automatische Failover und Backup-Orchestrierung über pgBackRest in einem System. Hochverfügbarkeit behandelt Multigres als Consensus-Problem und will Split-Brain auflösen, ohne bereits bestätigte Commits zu verlieren – auf Basis unmodifizierter Postgres-Replikation und mit frei definierbaren Durability-Policies, etwa AZ-übergreifend. Das Pooling läuft über eine Zwei-Komponenten-Architektur aus multigateway und multipooler, die den Pooling-Modus nicht mehr manuell verlangt, sondern per eingebautem Parser kontextabhängig entscheidet.

Der Dämpfer steht im Kleingedruckten: Das namensgebende Sharding ist in v0.1 noch gar nicht enthalten – die Alpha ist ein Single-Shard-Cluster mit HA und Pooling, ausdrücklich nicht produktionsreif und ohne Backward-Compatibility-Garantie. Benchmarks sollen folgen – weitere Infos hier bei GitHub.

Parallel sammelt OpenRouter $113M Series B ein, angeführt von Alphabets CapitalG, mit NVIDIA, MongoDB, Snowflake und Databricks im Boot. Der LLM-Routing-Layer zwischen Agenten und Providern wuchs binnen sechs Monaten von 5 auf 25 Billionen Token pro Woche über 400+ Modelle. Die Investorenliste ist wohl die eigentliche Botschaft: Die Infrastruktur-Riesen wetten gemeinsam auf das Gateway als feste Größe im Multi-Model-Stack.

Supabase Series F

---

SpaceX-IPO: KI-Compute als Story

Am Freitag ging SpaceX an die Nasdaq – mit einer angepeilten Bewertung von rund 1,75 Billionen Dollar der größte Börsengang der Geschichte, der Musk zum Billionär machen dürfte. Die Listung bei etwa 135 Dollar je Aktie soll rund 75 Milliarden einbringen. Ein gut Teil der Investorenstory ist mittlerweile nicht Raketen, sondern KI-Compute.

Den handfesten Teil liefern die Mietverträge rund um xAIs Colossus-Cluster, das seit der Übernahme zu SpaceX gehört: Anthropic zahlt laut Filing 1,25 Milliarden Dollar pro Monat bis 2029 für die gesamte Kapazität von Colossus 1 in Memphis, Google ab Oktober 920 Millionen monatlich für rund 110.000 NVIDIA-GPUs – etwa die Hälfte dessen. Klingt nach gesicherten Einnahmen, hat aber einen Haken: Beide Deals lassen sich ab Ende 2026 mit 90 Tagen Frist kündigen.

Der spekulative Teil schwebt im Orbit. In einem Fireside-Video skizziert Musk bis zu einer Million KI-Satelliten mit Compute-Racks an Bord, Laser-Links und je 150 kW Spitzenleistung, gefertigt ab Ende nächsten Jahres in einer eigenen „Gigasat“-Fabrik und per Starship gestartet. Demonstriert ist davon bisher nichts – orbitale Rechenzentren bleiben Konzept. Dass wir dieses Märchen schon kennen, zeigt die CivAI-Analyse aus Ausgabe 222: Frontier-Training braucht Hunderttausende GPUs, also Hunderttausende Satelliten, ohne Upgrade-Pfad und mit Kessler-Risiko. Überfüllung im Orbit wischt Musk derweil weg – „Space is really big“. Die Astronomen, die gegen die Konstellation protestieren, sehen das anders.

Mal schauen, was da passiert. Hast du Aktien gezeichnet und bekommen? Wie läufts?

Elon Musk wants to put 1 million AI satellites in space. Here’s how SpaceX could do it

---

---

HTTP/2 Bomb (CVE-2026-49975)

Codex (OpenAIs Coding-Agent) hat eine remote DoS-Lücke gefunden, die in der Default-HTTP/2-Konfiguration von nginx, Apache httpd, Microsoft IIS, Envoy und Cloudflare Pingora steckt – veröffentlicht als HTTP/2 Bomb, CVE-2026-49975. Der Trick kombiniert zwei seit zehn Jahren bekannte Techniken: einen HPACK-Kompressions-Bomb (ein Byte auf der Leitung wird zur vollen Header-Allokation, tausendfach) und einen Window-Stall, der diese Allokationen über ein Zero-Byte-Flow-Control-Fenster dauerhaft im Speicher festhält. Ein Heimrechner an 100 Mbit/s macht einen Server damit in Sekunden unerreichbar; gegen Apache und Envoy hält ein einzelner Client 32 GB RAM in rund 20 Sekunden – Amplifikation bis 5.700:1. Shodan zeigt über 880.000 betroffene HTTP/2-Sites, viele zum Glück hinter CDN.

Zur Mitigation – ein Reboot ist nirgends nötig, ein Service-Restart bzw. Reload genügt:

• nginx: Upgrade auf 1.29.8+ (neue max_headers-Direktive, Default 1000). Achtung: Der Fix bricht laut Ubuntu das ABI und crasht mit externen Modulen, weshalb er in USN-8398-2 vorerst zurückgezogen wurde – hier genau hinschauen.
• Apache httpd: Ubuntu hat gepatchte Pakete für 22.04 bis 26.04 ausgeliefert (upstream mod_http2 2.0.41). Ohne Upgrade: Protocols http/1.1.
• IIS, Envoy, Pingora: zum Writeup-Zeitpunkt kein Patch (Envoy zog am 3. Juni nach). Sonst HTTP/2 deaktivieren oder einen harten Header-Count-Cap davorschalten.

Als Notnagel hilft ein enges Per-Worker-Memory-Limit (cgroups, ulimit -v), damit ein bombardierter Worker OOM-gekillt und neu gestartet wird, bevor die Maschine in den Swap rutscht. Lehrreich ist der AI-Winkel: Beide Hälften waren ein Jahrzehnt öffentlich, Codex hat nur erkannt, dass sie sich kombinieren lassen – und weil die Fix-Commits öffentlich sind, lässt sich daraus laut Autoren mit jedem fähigen Modell ein Exploit bauen.

Alles schon gepatched? Tja, die Ubuntu Pakete wurden erst mal wieder zurückgezogen – mal schauen, etwas ungeschickt.

Codex Discovered a Hidden HTTP/2 Bomb

---

Datacenter-GPU im Gaming-PC für 200£

Den Gegenentwurf zum Cloud-Token-Strom liefert Oscar Molnar, der für rund 200 Pfund eine ausrangierte Datacenter-GPU in seinen Gaming-PC gesteckt hat. Die Tesla V100 SXM2 mit 16 GB hat weder PCIe-Slot noch Stromanschluss – ursprünglich saß sie in NVIDIAs DGX-Servern und kommuniziert über NVLink. Ein inoffizieller SXM2-auf-PCIe-Adapter für etwa 50 Pfund bringt sie trotzdem ins Mainboard, neben eine RTX 4080. Macht zusammen 32 GB VRAM – so viel wie eine einzelne RTX 5090, nur zum Zehntel des Preises.

Das eigentlich Überraschende ist die Bandbreite: Der HBM2-Speicher der V100 von 2017 liefert 900 GB/s, mehr als die GDDR6X-bestückte 4080 (736 GB/s) und mehr als jeder aktuelle Mac – selbst der M5 Max kommt nur auf 614 GB/s. Für LLM-Inferenz, wo die Speicherbandbreite die Tokens pro Sekunde bestimmt, ist genau das der entscheidende Wert.

Darauf läuft Qwen3.6-27B-MTP in Q5_K_M (~19 GB) mit 128k-Kontext bei ~32 Tokens/s, dank Multi-Token-Prediction potenziell 50–60. Das Modell hatte ich in Ausgabe 233 vorgestellt – es spielt mit Claude Sonnet 4.6 in einer Liga. Die Haken bleiben hemdsärmelig: Der Adapter-Lüfter dröhnt mit 82 dB und lässt sich nur per PWM-Gefrickel zähmen; unter NixOS muss man Treiber (legacy_535), CUDA 12.2 und Kernel 6.6 exakt pinnen, weil NVIDIA Volta-Support ab Treiber-Branch 560 gestrichen hat; und nach einem Warm-Reboot verschwindet die V100 gern mal aus lspci. Für den Preis trotzdem ein absurd gutes Local-LLM-Setup.

I Put a Datacenter GPU in My Gaming PC for £200

---

Für Four Nines ist der Mensch zu langsam

Norberto Lopes, VP Engineering bei incident.io, rechnet vor, warum 99,99% Verfügbarkeit eine andere Kategorie ist als 99,95%: Statt rund 22 Minuten Downtime pro Monat bleiben nur noch 4 Minuten 23 Sekunden – und zwar als Gesamtbudget, jeden Monat. Sein Kernargument: Für Four Nines ist der Mensch zu langsam. Selbst ein idealtypisches 3-Uhr-Szenario – Page, aufwachen, Laptop auf, Runbook suchen, Befehl prüfen, Enter – frisst gut fünf Minuten. SLA gerissen, bevor der Engineer überhaupt richtig wach ist.

Die Konsequenz ist kein „schneller werden“, sondern den Menschen aus dem kritischen Pfad zu nehmen. Das System muss die ersten 15–30 Minuten autonom überstehen; der Mensch verifiziert dann nur noch, was die Automatik bereits getan hat. Dazu kommt die unbequeme Abhängigkeits-Mathematik: Drei voneinander abhängige Komponenten mit je 99,99% ergeben zusammen nur 99,97%. Als Googles PubSub im Januar 2025 sieben Minuten ausfiel, riss incident.io prompt das Monatsziel – seither laufen Telekom-Provider active/active auf getrennten Clouds. Das Muster kennen wir aus ihrem eigenen Oktober-Postmortem in Ausgabe 214.

Bei AI bleibt Lopes erfrischend unaufgeregt: fürs Diagnostizieren – Reasoning mit Evidenz – traut er den Modellen viel zu, bei der autonomen Remediation deutlich weniger. AI verkürze die Zeit zwischen „etwas ist kaputt“ und „wir wissen, was“ – das Überleben der ersten Minuten liefern aber Circuit Breaker, Failover und Redundanz.

Humans aren’t fast enough for 4 9’s

---

Die Serverless-Illusion: Pay per Use

„Pay for what you use“ ist ein Preismodell, keine Sparzusage – auf diesen Denkfehler führt David Iyanu Jonathan im DZone-Beitrag zurück, warum Serverless-Rechnungen so oft eskalieren. Man kann wenig nutzen und trotzdem viel zahlen, wenn der Stückpreis hoch ist. Sein Rechenbeispiel: Eine 24/7-API mit 2,6 Milliarden Invocations im Monat (rund 1.000 Requests/Sekunde) kostete 52.000 Dollar auf Lambda – dieselbe Last auf Kubernetes/EC2 mit Autoscaling und Reserved-Baseline nur 4.990 Dollar. Knapp 47.000 Dollar Mehrkosten pro Monat, nicht wegen Inkompetenz, sondern wegen eines falschen mentalen Modells.

Das Tückische sei die Begleitmannschaft, die im Lambda-Kalkulator fehlt: API Gateway pro Request, NAT Gateway pro GB plus Stundenrate, CloudWatch-Ingestion bei 0,50 Dollar/GB, dazu RDS Proxy für die Connection-Flut. Cold Starts löst man mit Provisioned Concurrency – und hat damit die Idle-Kapazität, die man vermeiden wollte, im neuen Kostüm zurück. Managed Services haben eigene Sockelkosten: OpenSearch Serverless verlangt mindestens vier OCUs, macht 691 Dollar im Monat für eine Demo-Umgebung, die man ein paar Dutzend Mal anfasst.

Sinnvoll bleibt Serverless für echt sporadische Event-Workloads – der nächtliche ETL-Job, der Stripe-Webhook, das S3-getriggerte Image-Resizing. Die Diagnosefrage: Läge die durchschnittliche CPU-Auslastung als Container über 30–40%, gehört die Last in einen Container; bei 2% ist Lambda günstiger.

Wo das sonst endet, illustriert die Sammlung von Rechnungs-Albträumen auf ServerlessHorrors. Ein gutes Beispiel aus der Praxis liefer außerdem Fathoms Kosten-Putzaktion aus Ausgabe 132.

The Serverless Illusion: When “Pay for What You Use” Becomes Expensive

---

Kelsey Hightower: Kubernetes, AI und der Ausstieg

Im Pragmatic-Engineer-Podcast spricht Gergely Orosz mit Kelsey Hightower – vom selbst angelernten DSL-Techniker zum Google Distinguished Engineer und einer der prägenden Stimmen moderner Infrastruktur. Zweieinhalb Stunden, aus denen ein paar Punkte für unsere Zwecke herausstechen.

Bei AI bleibt Hightower angenehm bodenständig. Founder, die ihn um Rat fragen, fordert er auf, ihr Startup einmal komplett ohne das Wort „AI“ zu erklären – was regelmäßig offenlegt, dass es einen einfacheren, billigeren Weg zum selben Ziel gibt. Beim Thema Agenten auf der nackten Infrastruktur wird er konkret: erst Guardrails und Kontext, dann loslassen. Seine trockene Begründung: „I’ve seen what humans do when you just give them the AWS console“ – man ahnt, was er von Agenten mit Vollzugriff hält.

Der eigentliche rote Faden ist aber finanzielle Unabhängigkeit – der Ausstieg auf dem Höhepunkt. Hightower deutet Geld als „Freiheits-Token“ um: nicht Statussymbol, sondern Mittel, um aus dem Spiel auszusteigen und nicht mehr für andere arbeiten zu müssen. Als Microsoft ihn mit einer Verzehnfachung seines Google-Gehalts abwerben wollte, zog Google nach – sein Marktwert war über Nacht ein anderer. Statt mehr Konsum optimierte er auf Ausstieg: genug haben, um aufhören zu können (FIRE Bewegung hier erklärt).

Der Schluss bleibt people-first: Technik ist Mittel zum Zweck. Passt zu seinem alten Plädoyer für Boring Technology aus Ausgabe 142 – langweilige Architektur fahren und die Zeit in das stecken, wofür Kunden zahlen. Schöner Kontrast zum KI-Goldrausch im Rest dieser Ausgabe.

Kubernetes and retiring at the top with Kelsey Hightower

---

Schnell geshippt ≠ richtig geshippt

Priya Gopalsamy, Engineering Managerin bei Target, seziert im Stack-Overflow-Blog ein Muster, das viele kennen: Der AI-generierte PR sieht sauber aus, Tests grün, Review unauffällig – und zwei Tage später crashed es in Produktion. Sie nennt es die „illusion of correctness“. Der Code kompiliert und folgt Mustern, aber die unsichtbaren Annahmen darunter – ein Feld sei immer gesetzt, ein Call idempotent, zwei Order-Status gleichwertig, interner Traffic vertrauenswürdig – stehen nirgends im Code und fliegen erst beim echten Edge-Case um 2 Uhr nachts auf.

Ihre Kern-These: Jedes System habe eine begrenzte Aufnahmefähigkeit für neuen Code. AI hebt das Produktionstempo, nicht diese Kapazität – wird die Lücke zu groß, frisst Debugging und Rollback den Zeitgewinn mehrfach wieder auf. Refactoring ist daher kein Aufräum-Tax, sondern ein Velocity-Multiplikator. Als Leitplanken dient das Akronym CATS:

• Contracts: Grenzen explizit machen – versionierte API-Specs und Event-Schemas, gegen die AI zuverlässiger generiert als gegen implizite Konventionen.
• Automated Verification: Tests, die Domain-Invarianten erzwingen statt nur Happy Path; Schema- und Security-Checks im CI.
• Telemetry: Logs, Metriken, Traces fangen Drift bei 0,3% Fehlerrate ab – nicht erst beim Umsatzeinbruch am Donnerstag.
• Simplification: Kopplung laufend abbauen, gebündelt in die Feature-Arbeit statt als Roadmap-Projekt.

Dass das keine Theorie ist, zeigte zuletzt Amazon, wo AI-Code mehrstündige Ausfälle auslöste (Ausgabe 227). Eigentlich vergeht ja keine Woche, wo man von einem Case liest, bei dem KI irgendwas radikal geändert oder gar gelöscht hat. Die Beachtung der Leitplanken halte ich daher für einen sehr interessanten und wichtigen Punkt.

You shipped it fast. But did you ship it right?

---

SQLite is all you need

Auf die DBOS-These „Postgres is all you need for durable execution“ antwortet das Obelisk-Team mit einer Zuspitzung: Für eine große Klasse durabler Systeme reiche sogar SQLite. Denn das Haltbare an Durable Execution ist der Workflow-State, nicht die Infrastruktur. Compute darf billig und wegwerfbar bleiben, solange der Fortschritt sicher persistiert ist – bei Obelisk in einem Execution Log, aus dem Workflows per Replay wiederhergestellt und Activities erneut versucht werden.

SQLite passt hier, weil es transaktionalen, durablen State ohne separaten Datenbankdienst liefert: kein Network-Hop, keine Control Plane, keine zusätzliche operative Angriffsfläche. Portabel wird das über Litestream, das SQLite-Änderungen asynchron auf S3-kompatiblen Object Storage streamt. Der ehrliche Haken: Die Replikation ist asynchron – ein Restore kann die jüngsten lokalen Writes verlieren, wenn das Volume vorher verschwindet. Für AI- und Experimentier-Workflows okay, eine hochverfügbare geteilte Datenbank ist es nicht.

Besonders charmant ist das für AI-Agenten: bursty, experimentell, am leichtesten zu durchschauen, wenn jeder Agent oder Tenant eine kleine, abgeschlossene State-Einheit besitzt. Eine Flotte winziger Server in Micro-VMs – jeder mit eigener SQLite-Datei und Object-Storage-Backup – schlägt das eine große Always-on-System: simpler, günstiger, bessere Fault Isolation. Wer echte Hochverfügbarkeit oder breite Skalierung braucht, nimmt weiter Postgres; alle anderen sollten nicht mehr Infrastruktur starten, als ihr State verlangt. Passt zum pgmicro-Ansatz für Agent-Workflows aus Ausgabe 229 und zur alten „SQLite reicht meistens“-Linie aus Ausgabe 93.

You shipped it fast. But did you ship it right?

---

Security-Incident: Anderes Spiel, andere Regeln

Wer schon mal mit dem Outage-Playbook in einen Security-Incident gestolpert ist, kennt den Reibungspunkt: Das Vorgehen, das bei kaputten Systemen funktioniert, wirkt im Breach-Fall plötzlich falsch dimensioniert. Art Kondratiev seziert auf dem Uptime-Labs-Blog, warum das so ist.

Sein Eingangsbeispiel ist ein Klassiker: Hohe CPU-Last auf zwei App-Servern, ein nicht im Deployment-Manifest vorgesehener Prozess wird entdeckt – und in dem Moment, in dem jemand „Crypto-Miner?“ in den Channel schreibt, übernimmt der Security-Lead. Der Public-Channel wird abgeklemmt, ein privater Kanal mit Legal aufgesetzt, der Status-Page-Update zurückgehalten und der verdächtige Prozess bewusst nicht gekillt – weil er das beste Fenster zur Aufklärung ist.

Kondratiev arbeitet fünf Treiber heraus, die diesen Modus erklären: adversarial root cause (gegen einen Menschen, nicht gegen einen Bug), unbekannte Timeline (man steigt mittendrin ein, ohne den Anfang zu kennen), konkurrierende Recovery-Definitionen (Service wieder grün vs. Angriffskette unterbrechen), defensible vs. effective response (regulatorische und versicherungstechnische Pflichten verschieben das Gewicht weg vom reinen Outcome) und Confidentiality als Default statt Open-by-default.

Die Lehre für SRE-Teams: Wenn Kommunikation während eines Incidents plötzlich restriktiv wird, ist das kein Misstrauen, sondern ein Wechsel des Bedrohungsmodells. Wer das vorab durchdacht und in Tabletop-Übungen geprobt hat, spart sich später viel Frust am Bridge. Für die Zusammenarbeit zwischen Engineering und Security ist gemeinsames Vokabular die halbe Miete – Teil 2 der Serie soll das praktische Vorgehen behandeln.

Why Security Incidents Feel Different from Outages

---

Schmunzelecke

Claude Code is finishing up your refactor.
It needs your approval for a few commands. Can you finish in time?

llmgame.scalex.dev spielt damit, dass wir einfach alles Ack’en, wenn Claude oder ChatGPT um Erlaubnis / Permissions für Dinge fragen.

---

💡 Link Tipps aus der Open Source Welt

Odysseus – Self-Hosted AI Workspace als ChatGPT/Claude Alternative

Odysseus ist ein self-hosted AI Workspace, der die UI-Erfahrung von ChatGPT und Claude auf eigener Hardware nachbaut – mit Chat, Agent, Deep Research, Email, Kalender, Dokumenten-Editor und persistentem Memory. Alles lokal, alles unter eigener Kontrolle.

Key Features:

• Chat: Jedes lokale Modell oder API anbinden – vLLM, llama.cpp, Ollama, OpenRouter, OpenAI, GitHub Copilot
• Agent: Tool-basierter Agent mit MCP, Web Search, File/Shell Access, Skills und Memory – übergibt man eine Aufgabe, arbeitet er sie selbstständig ab
• Cookbook: Scannt die eigene Hardware, empfiehlt passende Modelle (basiert auf llmfit), One-Click Download und Serving via vLLM/llama.cpp
• Deep Research: Mehrstufige Recherche mit Quellen-Synthese zu visuellen Reports (basiert auf Tongyi DeepResearch)
• Email: IMAP/SMTP Inbox mit AI-Triage – Urgency Reminders, Auto-Tag, Auto-Summary, Auto-Reply Drafts, Spam-Erkennung
• Kalender: Local-first mit CalDAV-Sync (Radicale, Nextcloud, Apple, Fastmail)
• Dokumente: Multi-Tab Editor für Markdown/HTML/CSV mit AI-Unterstützung – „du schreibst, AI assistiert“
• Memory & Skills: Persistenter Vektor-Speicher via ChromaDB, Agent lernt über Zeit dazu
• Model Compare: Blind-Tests zwischen Modellen ohne Bias
• PWA: Läuft auch auf dem Handy

Deployment via Docker, nativ auf Linux/macOS/Windows. Apple Silicon mit Metal GPU Support über natives Setup.

Mit 69k Stars eines der am schnellsten wachsenden Open-Source-Projekte im AI-Bereich. Odysseus versucht nicht weniger als eine komplette selbstgehostete Alternative zu ChatGPT Plus – und kommt erstaunlich weit. Chat und Agent sind solide, der Cookbook mit Hardware-Scanning und One-Click Model Serving senkt die Einstiegshürde für lokale Modelle enorm. Email und Kalender mit AI-Triage gehen über das hinaus, was andere Self-Hosted-Chat-UIs bieten.

https://github.com/pewdiepie-archdaemon/odysseus

pg_durable – Durable Execution direkt in PostgreSQL

pg_durable ist eine PostgreSQL-Extension von Microsoft, die langlebige, fehlertolerante Workflows direkt in der Datenbank ausführt. Jeder Schritt wird checkpointed – bei Crash, Restart oder Failover wird automatisch vom letzten Checkpoint fortgesetzt. Kein Redis, kein Temporal, kein externer Service.

Key Features:

• SQL-native Workflows: Workflows als Graph von SQL-Schritten definieren mit komponierbaren Operatoren (~> für Sequenz, |=> für Binding, df.if(), df.join(), df.loop())
• Durable Checkpointing: Jeder Schritt wird in PostgreSQL persistiert – überlebt Crashes, Restarts und Failovers
• Parallele Ausführung: Fan-out von unabhängigen Queries mit anschließendem Join
• Scheduling, Conditions, HTTP Calls: Erste-Klasse-Primitive für zeitgesteuerte Ausführung, Bedingungen und externe API-Aufrufe via df.http()
• Multi-User mit RLS: Row-Level Security isoliert Instanzen pro User, granulare Privilege Grants
• Zero Infrastructure: Läuft als Extension + Background Worker innerhalb von PostgreSQL

Für Teams, die ohnehin alles in PostgreSQL halten und sich bisher mit Cron-Jobs, Status-Tabellen und externen Orchestratoren herumschlagen, ist pg_durable ein konzeptioneller Befreiungsschlag. Workflow-Definition und -Ausführung direkt neben den Daten, mit dem gleichen Auth- und Backup-Modell.

https://github.com/lynxbase/lynxdb

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