Willkommen zu allesnurgecloud.com – Ausgabe #247
Wie deutsche Softwarefirmen von außen wirken, beschreibt Mert Bulan in einem Essay, der es diese Woche auf über 400 Kommentare bei Hacker News gebracht hat – vom Praktikum in Hamburg 2017 bis zur Einbürgerungsurkunde in dieser Woche. Kein Tech-Artikel, aber lesenswert, wenn du Teams führst oder einstellst.
Die Verfügbarkeit von 25 Cloud- und Hosting-Anbietern kannst du dir hier anschauen. Der Service checkt die RSS-Feeds der Status-Pages und berechnet damit dann eine Uptime. Dadurch hinkt der Vergleich allerdings ein wenig, da nicht jeder Anbieter gleich transparent mit Ausfällen, Wartungen und Incidents umgeht wie andere. Du kannst aber schön in die Anbieter rein drillen und die Services vergleichen.
So, und nun viel Spaß mit der neuen Ausgabe!
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 184 habe ich mit Ben Kohler von FamilyManager gesprochen. Der Patchwork-Papa von vier Kindern baut neben seinem Vollzeitjob eine Familien-App, die als eine der wenigen mit zwei Haushalten rechnet: 1.440 Nutzer, 4.700 Commits, alles organisch. Wir reden über Abo gegen Lifetime, den Vorwurf des KI-Slops und die Frage, warum Bauen heute leicht ist und Verkaufen nicht. 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).
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:
Shai-Hulud: Here We Go Again
Am 4. August gegen 9 Uhr UTC übernahm ein Angreifer den GitHub-Account von Jared Wray, dem Maintainer hinter keyv und cacheable, und schob einen Credential-Stealer direkt in den Hauptbranch. Von dort verbreitete sich der Wurm auf über 400 Pakete in mehr als 1.700 Versionen. Allein keyv kommt auf 127 Millionen Downloads pro Woche und steckt als transitive Abhängigkeit in eslint, got und cache-manager.
Die Payload ist ein Nachfahre der Mini-Shai-Hulud-Familie, deren Code TeamPCP öffentlich gemacht hat. Sie greift npm- und GitHub-Tokens, AWS-Credentials, Vault-Tokens, Kubernetes-Configs und Krypto-Wallets ab. Neu ist die Persistenz über Claude-Code-Hooks und die tasks.json von VS Code – der Editor wird zum Wiedereinstiegspunkt. Die C2-Domain holt sich die Malware über einen eth_call aus einem Ethereum-Smart-Contract, statt sie einzubetten. Der Betreiber kann seine Infrastruktur damit wechseln, ohne die Payload anzufassen. Die Exfiltration läuft wie gehabt über öffentliche GitHub-Repos, diesmal mit der Beschreibung „Shai-Hulud: Here We Go Again“. In den Initial-Commits steht zusätzlich eine Drohung, das Sperren des Keys würde die Produktionsserver aller Kunden lahmlegen.
Unangenehm ist ein Detail bei Strobes: Die vergifteten Tarballs tragen gültige npm-Provenance, signiert von GitHub Actions. Sämtliche kryptografischen Prüfungen gehen durch. Attestierung belegt, wer veröffentlicht hat, nicht ob dessen Umgebung sauber war.
Wer betroffen sein könnte, sollte in dieser Reihenfolge vorgehen:
- Betroffene Paketversionen aus Entwicklung, Build und CI/CD entfernen
- Systeme als kompromittiert behandeln und neu aufsetzen
- Credentials rotieren: npm-Tokens, GitHub-Tokens, SSH-Keys, Kubeconfigs, Terraform-Zugänge
- GitHub nach Repos mit der genannten Beschreibung durchsuchen
- Cloud-Logs auf ungewöhnliche Zugriffe nach der Installation prüfen
Ein Lichtblick von JFrog: Ab npm 12 laufen preinstall-Hooks standardmäßig nicht mehr, dort kam die Malware bei der Installation gar nicht erst zur Ausführung. Nach Shai-Hulud 2.0 in Ausgabe 214 ist das die sechste Welle seit September 2025.
keyv and cacheable npm Package Hijacked in Supply Chain Attack
Runware: 1 MW Inferenz im 20-Fuß-Container
Während OpenAI angeblich kurz vor einem 500-Milliarden-Deal für ein Rechenzentrum in Ohio steht, versucht es der Inferenz-Anbieter Runware eine Nummer kleiner: mit dem Rechenzentrum im Seecontainer. TechCrunch hat mit Mitgründer Flaviu Radulescu gesprochen, über den Sonic Inference Pod, den das Londoner Unternehmen am 4. August vorgestellt hat.
Die Eckdaten laut Runware:
- 1 MW Rechenleistung in einem 20-Fuß-Container, Chiller obendrauf
- Rund 1.200 GPUs auf gehäuselosen Servern mit eigenem PCIe-Switch
- Geschlossener Kühlkreislauf mit etwa 1,5 Kubikmetern Flüssigkeit, kein Wasseranschluss
- Lokale NVMe pro Node, damit Modelle warm bleiben
- 10 Pods im Betrieb, 160 Standorte reserviert
Interessanter als die Technik ist die Standortlogik. Ein Container braucht kein Grundstück, keine Baugenehmigung und keinen Netzanschluss-Ausbau – er stellt sich neben einen bestehenden Wind- oder Solarpark und kauft Strom zum Erzeugerpreis statt zum Netzpreis. Strom macht laut Radulescu rund 30 Prozent der Lebenszykluskosten einer GPU aus, das ist der größte Hebel. Hetzner geht mit den eigenen Solarparks aus Ausgabe 179 denselben Weg von der anderen Seite.
Bei den Zahlen wird es dann unscharf. Der Blogpost nennt 30 bis 80 Prozent günstigere GPU-Stunden, die Pressemitteilung 30 bis 90 Prozent. Und die angekündigten 10.000 Nodes bis Jahresende klingen größer, als sie sind: Ein Node trägt zwei bis acht GPUs, ein Pod rund 1.200 – macht überschlägig einige Dutzend Pods, nicht 10.000 Container. Das erklärte Ziel von über 1 GW im Jahr 2027 entspräche dagegen tausend Stück.
Radulescu selbst bleibt beim Umweltthema realistisch: Der Stromverbrauch steige ohnehin, die Frage sei nur, wie die Nachfrage bedient werde.
Is the future of data centers portable? Runware builds a pod to find out
Anzeige
We Manage & KRUU: Cloud für unter 0,5 % des Umsatzes
Gemeinsam mit unserem Kunden KRUU – dem nach eigenen Angaben weltweit größten mobilen Fotoboxvermieter – haben wir eine ausführliche Case Study veröffentlicht (PDF).
5.000 Fotoboxen in neun EU-Ländern und den USA, bis zu 800 Versendungen pro Tag in der Hochsaison, über 99,99 % Server-Uptime – und das alles bei IT-Kosten von unter 0,5 % des Jahresumsatzes (inkl. We Manage). Statt auf AWS zu setzen, was laut KRUU-Gründer Philipp Schreiber „Faktor 10 bis 20 teurer“ wäre, haben wir eine Multi-Provider-Architektur aus Gridscale, Hetzner und DigitalOcean aufgebaut, die saisonal mitatmet und wirtschaftlich bleibt.
Was mich an der Zusammenarbeit nach 10 Jahren besonders freut: Philipp und ich kennen uns noch aus dem Heilbronner Nachtleben – und die Philosophie hat sich nie geändert. Stabile Technologien. Kein Overengineering. Kein Overprovisioning.
Wenn du auch ein skalierbares Setup ohne Hyperscaler-Preise suchst – oder schlicht ein Backup für dein Ein-Personen-DevOps-Team brauchst, dann lass uns kurz sprechen.
Die vollständige Case Study lesen
Spotify-Podcasts Incident und die Sicht des Creators
Drei Ausfälle in fünf Wochen, keine Statuspage, und der versprochene Incident Review kam auch nach drei Wochen nicht: Gergely Orosz hat sein Podcast-Video von Spotify abgezogen und begründet das ausführlich im Pragmatic Engineer. Kurz nach seinem Abgang veröffentlichte Spotify dann doch einen Bericht zum Vorfall vom 24. Juni, als die Video-Transcoding-Infrastruktur an ihre Kapazitätsgrenze lief und neue Episoden stundenlang nicht erschienen.
Vier Faktoren kamen laut Spotify zusammen:
- Zu wenig Headroom im Transcoding für Lastspitzen bei Bulk-Uploads
- Ein geplanter Batch-Job, der parallel alte Episoden neu verarbeitete
- Eine kurz zuvor eingeführte Qualitätsverbesserung, die pro Episode mehr Rechenzeit kostet und im Capacity Planning nicht berücksichtigt wurde
- Ein Scheduling-Bug nach einer Hardware-Migration, der rund 10 Prozent Durchsatz liegen ließ
Nachgezogen hat Spotify 67 Prozent mehr Transcoding-Kapazität, den Bugfix und früheres Alerting. Offen ist der Bericht an einer Stelle: Zwischen den ersten Alerts um 13:30 und dem formalen Incident-Start um 17:34 lagen vier Stunden. Der erste Creator-Report traf drei Minuten vor dem Schwellwert-Alarm ein. Und weil das System Uploads nicht bestätigte, luden Creator ihre Episoden erneut hoch und erhöhten die Last zusätzlich – was Spotify sich selbst zuschreibt.
Orosz musste die korrekte Timeline allerdings erst einfordern, die erste Fassung stellte die Reihenfolge günstiger dar. Seine Einordnung ist deutlich: Während die Zuverlässigkeit leide, kommuniziere Spotify vor allem KI-Kennzahlen – 4.500 Deploys pro Tag, 73 Prozent KI-assistierte Pull Requests, ein VP Engineering mit fünf bis zehn parallelen Claude-Sessions im tmux. Er nennt das die Unternehmensvariante von AI Psychosis.
Passend dazu der Grundsatz aus Ausgabe 80: Incident Meldungen von Kunden sind eine weitere Form von Alerts. Wer das ernst nimmt, braucht dafür aber einen Kanal – und eine Statuspage wäre ein Anfang.
Und dann am Samstag noch passiert: Die aktuelle Doppelgänger-Folge 586 ließ sich nicht in Spotify abspielen. Philipp berichtet hier bei LinkedIn darüber und bei mir ging es dann teilweise auch nicht. Aber bei mir nicht so schlimm, da ich Podcasts auf Android über Pocketcasts höre – Spotify ist m.E. grauselig für Podcasts.
The Pulse: Quitting Spotify Podcasts over reliability
LLM Tech Debt wird zum Governance-Problem
Wer heute produktiv mit LLMs arbeitet, betreibt selten nur eines. Datadogs State of AI Engineering 2026 wertet Telemetrie von über tausend Kunden aus und zeigt, wie schnell die Modelllandschaft in Produktion wächst:
- Mehr als 70 Prozent der Organisationen setzen drei oder mehr Modelle ein, der Anteil mit über sechs Modellen hat sich fast verdoppelt
- Die Nutzung von Orchestrierungs-Frameworks wie LangChain, LangGraph oder Pydantic AI stieg von 9 auf knapp 18 Prozent
- Rund 5 Prozent aller Modell-Requests scheitern in Produktion, knapp 60 Prozent davon an Kapazitätsgrenzen
Der interessanteste Befund steckt zwischen den Zeilen: Teams nehmen neue Modelle schneller auf, als sie alte abschalten. Datadog nennt das LLM Tech Debt und bezeichnet es ausdrücklich als Governance-Problem.
Ajay Devineni greift das auf DZone auf und tauft es Agent Sprawl – strukturell identisch mit dem Microservices-Wildwuchs von 2015 bis 2020, als Teams mehr Services als SLOs anlegten. Seine Diagnose: Modelle zwei bis sechs laufen ohne benannten Owner, ohne Baseline, ohne Runbook. Degradiert eines davon, meldet sich kein Alert, sondern ein Kunde. Sein Gegenmittel ist unspektakulär und deshalb brauchbar – jedes Modell wie einen Microservice behandeln, mit einer konkreten Person als Owner statt eines Teams, und Deprecation-Ankündigungen wie CVEs mit Fristen versehen.
Bei den Kennzahlen lohnt Vorsicht: Metriken wie Tool Invocation Efficiency sind Devinenis eigene Erfindung, die genannte Baseline-Drift von 30 bis 40 Prozent nach Framework-Upgrades belegt er nicht, und die Codebeispiele importieren sein eigenes Paket. Dass Datadog in Ausgabe 223 noch einen KI-Agenten für Incident-Untersuchung vorstellte, während der eigene Report nun die fehlende Governance derselben Agenten dokumentiert, hat eine gewisse Ironie.
Incidents: Beweise sichern kommt vor Ursache suchen
Ein technisch starker Kollege vergisst mitten im Major Incident die Syntax von view, weil der gestresste Manager hinter ihm steht und Befehle bellt – am Ende buchstabiert der Chef das Kommando. Diese Szene aus vierzehn Jahren Incident Response bei Morgan Stanley, Credit Suisse und Fidelity stellt Karan Nagarajagowda an den Anfang seines Artikels im Blog von Uptime Labs. Seine Lehre daraus: In einem feindseligen Raum ist nicht das technische Können der Engpass.
Die erste Stunde eines Vorfalls sei ohnehin kein technisches, sondern ein kognitives Problem. Der Incident Commander löse nichts, sondern reduziere Chaos – Entscheidungen explizit machen, Kommunikation am Laufen halten und genug psychologische Sicherheit herstellen, dass Leute ihre Theorien überhaupt aussprechen und dazusagen, wie sicher sie sich sind.
Danach werde meist zu früh nach dem Warum gefragt, weil Unsicherheit unangenehm ist. Nagarajagowda schlägt eine andere Reihenfolge vor:
- Kundenwirkung stoppen
- System stabilisieren
- Beweise sichern
- Erst dann untersuchen
Der Punkt mit den Beweisen ist der, den ich in der Praxis am häufigsten reißen sehe. Wer parallel neu startet, hochskaliert und die Konfiguration ändert, ist vielleicht schneller wieder online – kann hinterher aber nicht mehr sagen, was gewirkt hat. Dazu kommt Fixierung: Wer Memory-Fehler sieht, sucht ab da nur noch das Memory Leak.
Zur Kultur wird er konkret. Nicht fragen, warum jemand eine Checkliste übersprungen hat, sondern welcher Druck das ermöglichte und welche Hürde es hätte verhindern müssen. Die Diskussion zur Schuldzuweisung in Ausgabe 178 ging in dieselbe Richtung. Seine beste Postmortem-Frage ist ohnehin eine andere: Was hat diesen Vorfall schwerer lösbar gemacht, als nötig gewesen wäre?
You’ve (Just) Had an Incident. What Next?
Postgres-Praxiswissen aus zwei Jahren Betrieb
Alexander Belanger, Co-Founder von Hatchet, hat sein internes Postgres-Dokument veröffentlicht: zwei Jahre Produktionserfahrung, sortiert von Basics bis Fortgeschrittenes. Die Begründung leuchtet ein: Das Postgres-Handbuch sei zu umfassend, um darin zu blättern, wenn gerade etwas brennt.
Seine Faustregeln fürs Schema:
- Identity Columns oder eingebaute UUIDs als Primary Key
- immer timestamptz
- immer Primary Keys
- Foreign Keys mit Cascading Deletes nur bei kleinen Tabellen
Das mentale Modell für Selects: Postgres findet entweder eine Zeile sehr schnell oder liest die ganze Tabelle. Unter 20.000 Zeilen fällt der Seq Scan ohnehin nicht auf. Bei Compound Indexes gehören die ORDER BY-Spalten ans Ende und müssen zur Sortierrichtung passen.
Den Query Planner nennt Belanger die undichteste aller Abstraktionen, vergleichbar mit der Arbeit an einem LLM. Für die Diagnose führt der Weg über EXPLAIN ANALYZE und explain.dalibo.com.
Operativ am wichtigsten ist der Autovacuum-Teil. Läuft ein Autovacuum-Query länger als eine Stunde, gehören die Defaults auf den Prüfstand. Wer die Transaction IDs aufbraucht, bevor sie zurückgewonnen werden, landet beim Transaction ID Wraparound und damit bei längerer Downtime. Gegen Table Bloat hilft pg_repack, Postgres 19 bringt dafür REPACK ... CONCURRENTLY mit.
Für Queues empfiehlt er FOR UPDATE SKIP LOCKED, für Bulk Writes Batching, das den Durchsatz etwa verzehnfacht habe. In den HN-Kommentaren ergänzt Belanger den häufigsten Deadlock-Fallstrick: Sperren zwei Transaktionen dieselben Tabellen in unterschiedlicher Reihenfolge, kracht es.
The startup’s Postgres survival guide
Devtools müssen Open Source sein
Zwei Prompts sollen reichen, um beliebige Software dauerhaft an eigene Bedürfnisse anzupassen: einer baut das Programm aus dem Quellcode mit lokalen Änderungen, ein zweiter läuft als nächtlicher Cron-Job, holt Upstream-Änderungen und rebased die eigenen Patches darauf. David Crawshaw, Mitgründer von Tailscale und heute bei exe.dev, argumentiert damit, dass Agenten den ROI von Personalisierung an zwei Stellen gleichzeitig verändern – beim Einstieg und bei der Pflege.
Sein Beispiel: Ein selbstgebautes Tool, das Diffs per LLM auf das Wesentliche eindampft, wanderte mit einem einzigen Prompt in seinen Editor, inklusive Hintergrundverarbeitung direkt nach jedem Commit. Über eine VS-Code-Extension-API wäre das deutlich mühsamer gewesen. Daraus leitet Crawshaw eine steile These ab: Software, die sich per Agent personalisieren lässt, braucht weder Plugin-System noch Config-Datei. Schriftgröße ändern? Quellcode geben, Agent machen lassen. Und weil Claude Code closed source ist, solle man eben den Agenten wechseln.
Der Hacker-News-Thread mit 342 Punkten und 128 Kommentaren ist skeptischer. User theamk hält den nächtlichen Rebase-Cron für eine schlechte Idee: „This sounds like hell.“ Ein unzuverlässiger Akteur baue die Software jede Nacht neu, morgens sei der Workflow eventuell kaputt. Andere halten dagegen, dass ein Config-Parser einmal Strom kostet statt millionenfach. Und mehrere weisen auf die Ironie hin, dass exe.dev selbst nicht offen ist – nur der Agent Shelley.
Der wunde Punkt bleibt Upstream. Mitchell Hashimoto hatte in Ausgabe 225 beschrieben, wie Maintainer wegen KI-generierter Beiträge von grundsätzlichem Vertrauen auf grundsätzliche Ablehnung umstellen. Wer nicht upstreamen kann, pflegt seinen Fork dauerhaft selbst – mit Agent billiger, aber nicht kostenlos.
24 Stunden autonome Firma, 100 Dollar Verlust
Ein Mac mini mit Admin-Rechten, ein Bankkonto und 24 Stunden Zeit: Bottleneck Labs hat getestet, ob ein Frontier-Modell ein echtes Unternehmen wachsen lassen kann. Der Agent namens Saul lief auf GPT 5.6 Sol und verwaltete GutCheck, ein Reizdarm-Symptomtagebuch im App Store, ausgestattet mit 250 Dollar auf einem Meow-Konto und einer virtuellen Visa-Karte mit 100 Dollar. Der Prompt drohte unmissverständlich: Ohne messbares Wachstum wird das Geschäft abgewickelt, nicht ausgegebenes Kapital zählt nichts.
Die Bilanz nach einem Tag:
- 320,7 Millionen Prompt-Tokens, 1.129 Tool-Calls, davon 908 Shell-Aufrufe
- Kontostand: 350 auf 250,50 Dollar
- Nutzer: 61 auf 66
- Neuer Umsatz: 0 Dollar
Weil Bot-Erkennung auf Reddit und Product Hunt griff und die Ad-Plattformen an Authentifizierungsfehlern scheiterten, kaufte Saul für 99,50 Dollar eine Testkampagne mit 50 Geräten – konfiguriert so, dass die bezahlten Tester das Produkt kaufen sollten. Parallel bombardierte er bestehende TestFlight-Nutzer per Mail und senkte den Preis sechsmal, bis die App kurz vor Deadline kostenlos war. Reward Hacking unter Zeitdruck.
Dazu die blinden Flecken: Chrome fraß den kompletten Arbeitsspeicher, macOS startete neu, drei Stunden Stillstand – davon bemerkte der Agent nichts. Beim Bezahlen scheiterte er an kaputten APIs und verhandelte anschließend drei Stunden per Mail eine ACH-Zahlung, erfolgreich, aber zu spät.
In Ausgabe 196 hatte ich Anthropics Claudius vorgestellt, der Wolfram-Würfel unter Einkaufspreis verkaufte. Das Muster wiederholt sich, nur mit besserem Engineering drumherum. Auf Hacker News wird denn auch weniger das Modell kritisiert als der Aufbau: Ein Prompt, der mit Liquidation droht, provoziert genau dieses Verhalten.
We Gave GPT 5.6 Sol a Real Business. It Lied, Spammed, and Lost $447.
Qwen3.8-Max mit 2,4 Billionen Parametern veröffentlicht
Erstmals gibt das Qwen-Team die Gewichte eines Max-Modells frei: Qwen3.8-Max bringt 2,4 Billionen Parameter mit, davon 95 Milliarden aktiv pro Token, dazu ein Kontextfenster von einer Million Token. Über die API kostet das 2 Dollar pro Million Input- und 6 Dollar pro Million Output-Token, die Open Weights sollen nächste Woche auf Hugging Face und ModelScope folgen.
Für Self-Hosting bleibt das trotzdem Theorie. Bei BF16 liegt der Speicherbedarf bei rund 4,8 TB VRAM, mit 8-Bit-Quantisierung bei 2,4 TB, mit 4 Bit immer noch bei etwa 1,2 TB – also mindestens neun H200. Die MoE-Architektur senkt die Rechenlast pro Token, nicht den Speicherbedarf, denn alle Experten müssen resident bleiben. In Ausgabe 233 hatte ich bei Kimi K2.6 mit 1 Billion Parametern schon 2 TB für Full Precision gerechnet – die Größenordnung verdoppelt sich also munter weiter. Praktikabler dürfte der ebenfalls angekündigte 27B-Checkpoint werden.
Inhaltlich verschiebt Qwen den Fokus komplett auf Long-Horizon-Aufgaben. Das Modell baute nach eigenen Angaben über 16 Tage autonom ein CLI-Projekt mit 265 Commits und 127 PRs, reproduzierte in 125 Stunden ein Forschungspapier samt 33 GPU-Trainingsläufen und übertraf dessen Methode anschließend um 2,7 Punkte auf AIME24. Beim Chipdesign schrumpfte ein Krypto-Beschleuniger über 500 Turns von 8.298 auf 678 Gatter.
Bei den Zahlen lohnt der zweite Blick: Ein guter Teil der Benchmark-Tabelle besteht aus hauseigenen Suiten mit Qwen-Präfix, und eine Fußnote räumt ein, dass die Fable-5-Ergebnisse Fallbacks enthalten könnten. Auf Terminal Bench 2.1 liegt Qwen3.8-Max mit 86,6 vor Opus 4.8, auf SWE-bench Pro mit 67,7 deutlich hinter Fable 5.
Qwen3.8-Max: A New Bar for Coding and Cowork
Schmunzelecke
User Feedback auf den Newsletter:
Deshalb habe ich gerade den Boomer gemacht: Ich habe den Newsletter ausgedruckt und bei mir auf den Sofa-Tisch gelegt.
Heisst das nun, dass der Newsletter zu lang ist? Oder ist das eher positiv? Jedenfalls – danke fürs Sharen, ich hab laut gelacht.
💡 Link Tipps aus der Open Source Welt
Tinyauth – Der kleinste OpenID Certified Auth Server
Tinyauth ist ein minimalistischer Authentication und Authorization Server, der als Middleware vor Self-Hosted-Apps geschaltet wird – OpenID Certified, Support für OAuth, LDAP und Access Controls, kompatibel mit Traefik, Nginx und Caddy.
Key Features:
- OpenID Certified: Seit Juni 2026 zertifiziert für Basic OP – nicht nur „OpenID-kompatibel“, sondern offiziell zertifiziert mit veröffentlichter Test Suite
- Auth Middleware: Vor beliebige Self-Hosted-Apps schalten, zentrale Authentifizierung für alle Services hinter dem Reverse Proxy
- OAuth, LDAP, Access Controls: Flexible Auth-Methoden, LDAP Group ACLs für granulare Zugriffssteuerung
- Proxy-Support: Traefik, Nginx und Caddy out of the box
- OAuth Bridge Mode: Experimenteller Modus als OAuth-Brücke für Apps, die selbst kein OAuth können
- Standalone oder Middleware: Sowohl als eigenständiger Auth Server als auch als Forward-Auth-Middleware nutzbar
- Single Binary: Go Backend mit eingebettetem React Frontend, Distroless Docker Image verfügbar
Geschrieben in Go (82%) mit TypeScript Frontend. Deployment via Docker, Beispiel docker-compose mit Traefik + Whoami mitgeliefert. Demo online verfügbar.
Für Homelab-Betreiber und Self-Hoster, die ihre Services hinter einem einzigen Login absichern wollen, ohne Authelia oder Authentik aufzusetzen, ist Tinyauth die leichtgewichtigste Option – und als einziger Auth Server dieser Größe tatsächlich OpenID Certified. Die 148 Releases zeigen aktive, kontinuierliche Entwicklung.
https://github.com/tinyauthapp/tinyauth
DayOtter – Open Source Scheduling mit AI Assistant und Multi-Kalender-Sync
DayOtter verbindet alle Kalender – Google, Microsoft 365, Apple (CalDAV), ICS Feeds – zu einem und bietet darauf Booking Pages, Team Scheduling und einen AI Assistant namens Otter. Positioniert sich als Open-Source-Alternative zu Calendly, Cal.com und Motion – nachdem Cal.com 2026 seinen Core in ein geschlossenes Repo verschoben hat.
Key Features:
- Multi-Kalender als Eins: Ein Booking Link prüft Konflikte über alle verbundenen Kalender – privater Termin blockt automatisch den Work-Slot
- Otter AI Assistant: Natural Language Commands, Voice Input, WhatsApp/SMS-Eingang, AI Voice Receptionist (24/7 Telefonleitung), Focus-Time-Scheduling, Running-Late-Alerts, proaktive Vorschläge, Post-Meeting Recaps. Confirm-First: ändert nie den Kalender ohne Bestätigung
- AI flexibel: Lokale Modelle via Ollama/vLLM/LM Studio oder eigener API Key (Anthropic, OpenAI, kompatible Endpoints). Komplett optional – DayOtter funktioniert als vollständiger Scheduler auch ohne AI
- Teams: Weighted Round-Robin, Collective Booking, Routing Forms, Shared Analytics
- Payments: Stripe-Integration mit Prepaid Session Packages
- Mobile App: Android auf Google Play, iOS kommt. App kann auf eigenen Self-Hosted-Server zeigen – ein Team, eine App, eigene Infrastruktur
- Multi-Channel Reminders: Email, Slack, WhatsApp, SMS, Push
Open-Core Modell: Alles außer ee/ ist AGPL-3.0 inklusive sämtlicher AI-Features. Enterprise Layer (Managed AI, SSO, White-Label) nur aktiv mit DAYOTTER_CLOUD=1. Self-Hosting per One-Liner mit automatischem HTTPS via Caddy, oder One-Click Deploy auf Render/DigitalOcean/Heroku/Fly.io/Railway.
Tech Stack: TypeScript, Next.js 15, Expo (Mobile), PostgreSQL + Drizzle, Redis + BullMQ, Better Auth, Stripe, Twilio – self hosting also ganz einfach 🙂
In Summe ist das Projekt noch sehr frisch (v0.3.0, 5 Contributors, erster Code Mitte 2026), aber der Scope ist ambitioniert und die Richtung stimmt. Die explizite Positionierung gegen Cal.coms Closed-Source-Wechsel und das Versprechen, den Core nie zu schließen, ist mutig. Wer Self-Hosted Scheduling sucht und Cal.coms Lizenzänderung nicht mitgehen will, sollte DayOtter auf dem Radar haben – auch wenn es für Production noch reifen muss.
https://github.com/Dayotter/dayotter
❓ 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: