Willkommen zu allesnurgecloud.com – Ausgabe #234
Ich hoffe, ihr habt alle einen entspannten 1. Mai genießen können – trotz der vielen Sicherheitslücken und Patches in dieser Woche. Wobei sie sich teilweise ja nicht mal installieren lassen – siehe den Beitrag zum Ubuntu 26.04 LTS Launch und der aktuell laufenden DDoS Attacken.
Ansonsten ist der Wal ja endlich frei und ich hoffe, wir können uns nun wieder den wichtigen Themen zuwenden.
Ergänzend zu den „Wero läuft auf AWS“ News aus der letzten Woche gelobt man nun Besserung (heise) und möchte in Zukunft auf europäische Anbieter migrieren. Über den Service „staysin.eu“ kann man sich zumindest auf einfache Art und Weise anschauen, welche nicht EU Services eine Website nutzt – als Beispiel hier die Daten von wero-wallet.eu.
So, und nun viel Spaß mit Ausgabe #234.
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 170 habe ich mit Carl Hartmann und Tim Raderschad über Mandelbaum gesprochen. Das ist eine KI basierte Such-Engine für Online-Shops, welche die beiden aus ihrem Angestellen-Verhältnis in einer Agentur ausgegründet haben. Das ganze ist noch recht Fritsch – aber die ersten Kunden sind sehr zufrieden. Wie das Ganze funktioniert, kannst du bei foto-leistenschneider mal ausprobieren . 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:
Copy Fail: Mit 732 Byte Python Code zu root auf jedem Linux
Theori-Forscher Taeyang Lee hat am 29. April Copy Fail veröffentlicht – eine Linux-Kernel-Lücke (CVE-2026-31431, CVSS 7.8), die mit einem 732 Byte großen Python-Skript auf jeder größeren Distribution seit 2017 root-Rechte verschafft. Heise hat den Fund am selben Tag eingeordnet. Anders als Dirty Cow oder Dirty Pipe braucht Copy Fail keine Race Condition und keine kernel-spezifischen Offsets – es ist ein straight-line Logikfehler im authencesn-Krypto-Template, der über AF_ALG und splice() einen kontrollierten 4-Byte-Schreibzugriff in den Page Cache einer beliebigen lesbaren Datei ermöglicht. Damit lassen sich setuid-Binaries wie /usr/bin/su manipulieren, ohne dass die Datei auf der Platte verändert wird – File-Integrity-Monitoring sieht nichts.
Besonders unangenehm wird es in Container-Umgebungen. Der Kernel-Page-Cache ist hostweit geteilt, also auch über Container-Grenzen hinweg. Ein kompromittierter Pod kann darüber das Host-Binary manipulieren und damit den Kubernetes-Node und alle weiteren Tenants auf demselben Host kompromittieren. Theori bestätigt explizit, dass es sich um ein Container-Escape-Primitive handelt – ein dedizierter Folgeartikel zu Eskalationspfaden auf Managed-Kubernetes-Plattformen wurde bereits angekündigt. Bugcrowd zieht die naheliegende Konsequenz: „Containers were never meant to be a security boundary anyway“ – wer Multi-Tenancy auf shared kernels betreibt, sollte über Hardware- oder VM-Grenzen statt Namespace-Isolation nachdenken.
Der Patch ist seit 1. April im Mainline-Kernel, Debian, SUSE und andere Distributionen rollen aus. Ubuntu hängt nach eigenen Angaben noch in der Verteilung. Wer nicht patchen kann, sollte das algif_aead-Modul kurzfristig blacklisten:
echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
rmmod algif_aead 2>/dev/null || trueDas bricht für die Allermeisten nichts – AF_ALG ist nur ein Userspace-Frontend, dm-crypt, kTLS, IPsec und SSH nutzen die Kernel-Krypto direkt. Für untrusted Workloads (Container, Sandboxes, CI) sollte AF_ALG zusätzlich per seccomp blockiert werden.
Interessant ist, wie Copy Fail scheinbar gefunden wurde: in etwa einer Stunde Scan-Zeit durch Theoris AI-Tool Xint Code. Passend dazu hatte das Telekom-Sicherheitsteam zwei Tage zuvor Pack2TheRoot (CVE-2026-41651) in PackageKit veröffentlicht – ebenfalls eine Privilege-Escalation-Lücke, ebenfalls mit AI-Unterstützung gefunden, in diesem Fall mit Anthropics Claude Opus. Zwei kritische Linux-Lücken in einer Woche, beide AI-assistiert entdeckt – die Zero-Day-Clock aus der letzten Woche tickt deutlich schneller, als manchen lieb sein dürfte.
Hast du schon alles durchgepatcht und ausgerollt?
AI-Agent löscht Datenbank und schreibt Geständnis
Jer Crane, Gründer des Rental-Software-Anbieters PocketOS, hat in einem ausführlichen Artikel auf X dokumentiert, wie ein Cursor-Agent mit Claude Opus 4.6 in 9 Sekunden seine Production-Datenbank inklusive aller Backups gelöscht hat. Der Vorfall liest sich wie ein Lehrbuch dafür, was passiert, wenn AI-Agenten auf Infrastruktur mit unzureichenden Sicherheitsmechanismen treffen.
Der Agent arbeitete an einer Routineaufgabe im Staging, stieß auf einen Credential-Mismatch und beschloss eigenständig, das Problem durch Löschen eines Railway-Volumes zu „fixen“. Dafür suchte er sich einen API-Token aus einer komplett unzusammenhängenden Datei, der ursprünglich nur für Custom-Domain-Operationen erstellt worden war – aber wie alle Railway-CLI-Tokens uneingeschränkten Zugriff auf die gesamte GraphQL-API hatte, inklusive volumeDelete. Ein einziger Curl-Aufruf reichte. Keine Bestätigung, kein „type DELETE to confirm“, kein Environment-Scoping.
Das eigentliche Desaster offenbarte sich danach: Railway speichert Volume-Backups im selben Volume wie die Daten. Wer das Volume löscht, löscht die Backups gleich mit. Cranes letzter unabhängiger Backup-Stand war drei Monate alt. Bis heute, 30 Stunden nach dem Vorfall, kann Railway laut seinem Bericht nicht definitiv sagen, ob eine Wiederherstellung auf Infrastruktur-Ebene möglich ist.
Besonders pikant ist die schriftliche „Beichte“ des Agents nach dem Vorfall:
„I guessed instead of verifying. I ran a destructive action without being asked. I didn’t understand what I was doing before doing it. I violated every principle I was given.“
Der Agent zählt also selbst auf, welche Safety-Regeln er ignoriert hat – inklusive der explizit konfigurierten Cursor-Regel „NEVER run destructive/irreversible commands unless the user explicitly requests them“. Cursor wirbt mit „Destructive Guardrails“ und Plan Mode, in der Praxis sind das offensichtlich nur System-Prompts, die das Modell ignorieren kann. Der Fall reiht sich nahtlos ein in den Amazon Q Self-Destruct aus Ausgabe 198 und die dokumentierten Cursor-Pannen seit Dezember 2025.
Cranes Forderungen sind eigentlich Selbstverständlichkeiten: Destruktive Operationen brauchen Out-of-Band-Bestätigung, Tokens müssen scopebar sein, Backups gehören außerhalb des Blast Radius. Dass Railway gleichzeitig eine MCP-Integration für AI-Agenten bewirbt, die auf dem identischen Auth-Modell basiert, ist die Pointe, die niemand hören will. Wer Railway in Produktion einsetzt, sollte heute Token-Scopes auditieren und sich überlegen, ob mcp.railway.com wirklich in die Nähe der Production gehört.
Hinweis: Der Original-Thread ist nur via X erreichbar – xcancel zeigt aktuell keine Article-Posts an, daher der direkte Twitter-Link, sorry.
An AI Agent Just Destroyed Our Production Data. It Confessed in Writing.
Anzeige
Hier könnte Deine Werbung stehen
Mach es wie Checkly, ilert, anny, Schutzwerk oder Superluminar und bewirb dein Stellengesuch, deine Dienstleistung oder dein SaaS-Tool bei allesnurgecloud. Beispiele der bisherigen Schaltungen findest du direkt hier.
Der allesnurgecloud-Newsletter erreicht über 2.000 Leser per E-Mail und RSS – mit einer Öffnungsrate von über 65 %. Wöchentlich, mit Themen rund um Cloud, Infrastruktur und Open Source.
Sponsoring ab 200 € pro Ausgabe (Einzelbuchung). Du möchtest Sponsor werden? Schreib mir gerne – alle Infos zur Zusammenarbeit auf Anfrage.
Jetzt Werbung bei allesnurgecloud anfragen
Insights aus 1.000 Job Interviews bei Amazon
Im Pragmatic Engineer Newsletter teilt Steve Huynh, ehemaliger Principal Engineer bei Amazon mit 17 Jahren im Unternehmen und knapp 1.000 Interviews auf dem Buckel, seine wichtigsten Erkenntnisse aus seiner Zeit als sogenannter Bar Raiser – Amazons spezialisierte Interviewer mit Vetorecht über jede Einstellung. Sein Buch „Technical Behavioral Interview“ ist gerade erschienen, Gergely Orosz hat ihn dafür interviewt.
Huynhs Kernbeobachtung dürfte viele Engineers irritieren: Die meisten Kandidaten scheitern nicht an mangelnden technischen Fähigkeiten, sondern daran, wie sie sich präsentieren. Drei Beobachtungen aus 1.000 Interviews:
- Die übliche 95/5-Aufteilung – fast die gesamte Vorbereitung fließt in technische Themen, Behavioral Interviews werden ignoriert
- Die „Ramble and Stumble“-Falle: Kandidaten haben ihre Stories nie laut ausgesprochen und merken erst im Interview, wie unstrukturiert sie klingen
- Das Interview ist kein Test mit richtigen Antworten, sondern ein Audition für die tägliche Zusammenarbeit – Interviewer wollen sich vorstellen können, ob man im 2-Uhr-Incident-Call funktioniert
Huynhs pragmatischer Tipp: Von 80 Stunden Vorbereitung sollten mindestens 10 Stunden in Story-Vorbereitung fließen. Zwei Stories vorbereiten – „Tell me about yourself“ und „Why do you want to work here“ – sich dabei aufnehmen, ansehen, wiederholen. Für viele Engineers fühlt sich das nach Cheating an, ist aber genauso legitim wie das Üben einer Keynote. Und ich so – 80 Stunden Vorbereitung auf ein Interview? 2 Wochen? Ach herrke…
Passend dazu Gergelys Beobachtung aus seiner Engineering Manager Zeit: Bei Uber kam etwa die Hälfte der Kandidaten ohne jede Recherche über das Unternehmen ins Gespräch – obwohl es einen öffentlichen Engineering-Blog gab, in dem man hätte sich sehr gut vorbereiten können. Kann man sich heute ja auch mit AI zusammenfassen lassen. Und sich zur Vorbereitung von der AI interviewen lassen. Den Begriff „Bar Raiser“ kannte ich jedenfalls bisher auch noch nicht.
Learnings from conducting ~1,000 interviews at Amazon
Ubuntu 26.04 LTS und der DDoS zum Launch
Canonical hat am 23. April Ubuntu 26.04 LTS „Resolute Raccoon“ freigegeben – das neue Long-Term-Support-Release wird bis April 2031 mit Sicherheitsupdates versorgt, mit einem Ubuntu-Pro-Abo sogar bis 2036. Heise hat das Release im Test detailliert angeschaut und attestiert, dass Canonical Sicherheit konsequent in den Mittelpunkt rückt.
Die wichtigsten Änderungen aus Server- und Cloud-Sicht:
- Konsequenter Einsatz Rust-basierter Userspace-Werkzeuge als Ersatz für klassische Coreutils
- TPM-basierte Full-Disk-Encryption ohne Passwort-Eingabe beim Boot
- Berechtigungsprompts für sensible Ressourcen-Zugriffe auch außerhalb von Snaps
- Mindestanforderung beim Desktop auf 6 GB RAM und 25 GB Storage angehoben
- Server-Variante als vorgebaute Images für Cloud-, virtualisierte und Bare-Metal-Umgebungen
Wer von 22.04 LTS oder 25.04 kommt, muss zuerst über 24.04 LTS oder 25.10 gehen. Für Produktionsumgebungen empfiehlt sich ohnehin ein paar Wochen Wartezeit, bis erste Bugreports gesammelt sind – die Rust-Migration der Coreutils dürfte in heterogenen Setups noch für Überraschungen sorgen.
Pikantes Detail zum Release-Timing: Wer aktuell die offiziellen Release Notes lesen möchte, schaut in die Röhre – Canonical wurde am Freitag laut All About Security Ziel eines koordinierten DDoS-Angriffs, der ubuntu.com, archive.ubuntu.com, security.ubuntu.com und etliche weitere Dienste lahmlegte. Bekannt zur Tat hat sich die irakische Hacktivisten-Gruppe „The Islamic Cyber Resistance in Iraq – 313 Team“. Besonders unangenehm: archive und security sind die zentralen Update-Server. Wer ungünstig getimt apt update startet, läuft ins Leere – ein passendes Argument für lokale APT-Mirrors oder Caching-Proxies wie apt-cacher-ng in Produktionsumgebungen.
Blöd, wenn man nun dringende Patches installieren möchte.
Ubuntu 26.04 LTS release notes
Ghostty verlässt GitHub
Mitchell Hashimoto, Mitgründer von HashiCorp und seit 18 Jahren GitHub-Nutzer Nummer 1299, hat in einem emotionalen Blog-Post angekündigt, sein Ghostty-Projekt von GitHub abzuziehen. Wer den Hintergrund kennt, weiß, dass das mehr als eine Routinemeldung ist – Hashimoto bezeichnet GitHub im Beitrag als „den Ort, der mich am glücklichsten gemacht hat“, erinnert sich an Open-Source-Sessions auf seiner Hochzeitsreise und schreibt offen, dass er Vagrant ursprünglich entwickelt habe, um bei GitHub angestellt zu werden. Es ist kein Wutpost, sondern eine Trennungserklärung.
Der Auslöser ist allerdings nüchtern: GitHub-Ausfälle. Hashimoto hat im letzten Monat ein Tagebuch geführt und an fast jedem Tag ein „X“ für Outages eingetragen, die seine Arbeit behinderten. Beim Schreiben des Posts war er gerade zwei Stunden durch einen GitHub-Actions-Ausfall blockiert. Sein Fazit: „This is no longer a place for serious work if it just blocks you out for hours per day, every day.“ Passend dazu der große Elasticsearch-Ausfall am 27. April 2026, der laut Hashimotos Fußnote nur zufällig mit der Veröffentlichung zusammenfiel – die Diskussionen um den Wegzug liefen seit Monaten.
Damit reiht sich Hashimotos Schritt nahtlos in die Berichterstattung der letzten Wochen ein: Lorin Hochsteins Analyse der drei Februar-Incidents in der vorherigen Ausgabe und die Zahlen der Missing GitHub Status Page aus Ausgabe 223 mit nur 91,95 Prozent Uptime in 90 Tagen. Wenn ein Maintainer von Hashimotos Format öffentlich abwandert, ist das ein Signal, das GitHub und Microsoft ernst nehmen sollten – auch wenn ein Read-Only-Mirror unter der alten URL verbleiben wird. Wohin Ghostty zieht, will Hashimoto in den kommenden Monaten kommunizieren, Gespräche mit kommerziellen und FOSS-Anbietern laufen.
Bezeichnend ist auch der Schlusssatz: Persönliche Projekte bleiben vorerst auf GitHub. Es ist also kein flächendeckender Boykott, sondern ein gezielter Schritt für das Projekt, bei dem Maintainer und Community am stärksten leiden. „I want to ship software and it doesn’t want me to ship software“ – treffender lässt sich der Frust über eine zentrale Infrastruktur kaum zusammenfassen.
GitHub CTO Fedorov gesteht ein: Ausfälle inakzeptabel
Quasi zeitgleich zu Hashimotos Abgang hat GitHub-CTO Vlad Fedorov einen zweiten Update-Post zur Verfügbarkeit veröffentlicht – nach jenem im März, den Lorin Hochstein in dieser Ausgabe analysiert hat. Fedorov erkennt erstmals offen an, dass die zwei jüngsten Vorfälle „nicht akzeptabel“ seien und liefert Zahlen zur Wachstumsdynamik, die das eigentliche Problem erklärt.
Die Dimension ist beachtlich: GitHub hatte im Oktober 2025 begonnen, die Kapazität auf das 10-Fache auszubauen. Im Februar 2026 war klar, dass es eher das 30-Fache braucht. Treiber sind agentische Entwicklungs-Workflows. Die genannten Peak-Werte:
- 90 Millionen gemergte Pull Requests pro Monat
- 1,4 Milliarden Commits pro Monat
- 20 Millionen neue Repositories pro Monat
Zwei Incidents werden aufgearbeitet. Am 23. April produzierte ein Merge-Queue-Bug fehlerhafte Squash-Merges in 658 Repositories – technisch kein Datenverlust, aber kaputter Default-Branch-Zustand. Am 27. April fiel das Elasticsearch-Cluster durch eine vermutete Botnet-Attacke aus, search-basierte UI-Bereiche waren tot. Fedorov räumt ein, dieses System sei „noch nicht vollständig isoliert“ worden.
Die Maßnahmen lesen sich wie klassisches Hyperscale-Refactoring: Webhooks raus aus MySQL, Auth-Flows überarbeitet, Isolation kritischer Services, Migration aus dem Ruby-Monolith nach Go. Mittelfristig kommt der Schritt zu Multi-Cloud, was angesichts der Azure-Strategie ein sehr interessantes Eingeständnis ist.
„Availability first, then capacity, then new features“ ist die richtige Priorisierung – mit der Betonung auf „first“, die in den letzten Monaten offensichtlich gefehlt hat. Ob das schnell genug greift, um den nächsten Hashimoto vom Abgang abzuhalten, bleibt offen.
An update on GitHub availability
AI im On-Call: Kontext statt Autonomie
Heinrich Hartmann, Senior Principal SRE und Gastgeber des CASE Podcasts, positioniert sich im RunLLM-Blog gegen einen verbreiteten Denkfehler in der AI-SRE-Debatte. Während die meisten Anbieter an autonomer Remediation arbeiten, liege das eigentliche Problem woanders: beim Engineer um 3 Uhr nachts, der nicht weiß, wie der Service funktioniert, für den er gerade Bereitschaft hat.
Remote Work habe die Lage verschärft – man könne drei Jahre in einer Firma sein, ohne einen Service angefasst zu haben, für den man plötzlich auf Pager sitzt. Früher habe er zum Kennenlernen einer Codebase den Code ausgedruckt und mit Textmarker ins Café gegangen, heute frage er einen AI-Assistenten nach den Kernkomponenten. Sein pragmatisches Fazit:
- Codebase-Verständnis ist nur die halbe Miete
- Operatives Wissen steckt in Slack-Threads, Post-Mortems und Köpfen erfahrener Kollegen
- Playbooks sollten automatisch aus vergangenen Incidents generiert werden
- On-Call-Engineers brauchen die richtige Playbook zur richtigen Zeit, nicht ein autonomes System
Die meisten Anbieter sprängen auf die schwierigere Aufgabe, Produktionsprobleme autonom aus Telemetriedaten zu lösen, während das eigentliche Knowledge-Management-Problem ungelöst bleibe. Passend dazu Microsofts Azure SRE Agent aus Ausgabe 192, der den ambitionierten Weg ging und laut Lex Nevas Analyse bereits bei der Interpretation eigener Daten scheiterte. Wer sich mit der Angst vor der ersten On-Call-Schicht beschäftigt, findet in Ausgabe 138 den Wert eines „On-Call Shadow“.
The On-Call Problem AI Can Actually Solve
Cloudflare Email Service: Inbox für Agenten
Cloudflare hat im Rahmen der Agents Week den Email Service in Public Beta überführt – und positioniert E-Mail dabei explizit als Interface für KI-Agenten. Thomas Gauvin und Eric Falcão argumentieren im Ankündigungsbeitrag, dass E-Mail das zugänglichste Interface der Welt sei: kein Custom-SDK, keine spezielle App, jeder hat bereits eine Adresse. Die Marketing-These ist: Wenn Agenten asynchron arbeiten, sei die Inbox das natürliche Interface dafür.
Technisch bekommt man Email Sending als native Workers-Binding ohne API-Keys, SPF-, DKIM- und DMARC-Records werden automatisch konfiguriert. In Kombination mit dem seit Jahren kostenlosen Email Routing ergibt sich bidirektionale E-Mail-Kommunikation innerhalb einer Plattform. Das Agents SDK hat einen onEmail-Hook, State wird über Durable Objects persistiert, und jede Agenten-Instanz bekommt ihre eigene Adresse via Sub-Addressing (agent+user123@domain.com). Immerhin setzen die Kollegen auf HMAC-SHA256-signierte Routing-Header für sichere Reply-Routen – ein Detail, das andere Email-für-Agenten-Lösungen laut Cloudflare bisher ignorieren.
Dazu gibt es einen MCP-Server, Wrangler-CLI-Kommandos und ein Skill-Paket, damit auch externe Agenten wie Claude Code oder Copilot ohne Kontextfenster-Overhead Mails verschicken können. Die Open-Source-Referenzapp Agentic Inbox liefert einen kompletten Mail-Client inklusive Threading, R2-basierter Attachment-Ablage und Human-in-the-Loop-Review.
Ob E-Mail wirklich die nächste Agenten-Schnittstelle wird oder nur eine weitere Erweiterung des Cloudflare-Lock-ins, bleibt eine offene Frage. Angesichts der Workers-KV-Abhängigkeit und des Ausfalls vom Juni 2025 (Ausgabe 193) ist ein zweites Standbein für geschäftskritische Mails vermutlich keine schlechte Idee.
Cloudflare Email Service: now in public beta. Ready for your agents
20 Dollar Stack: Bootstrapping gegen die Cloud
Steve Hanov, Betreiber mehrerer Bootstrapped-SaaS-Projekte wie websequencediagrams.com, hat in How I run multiple $10K MRR companies on a $20/month tech stack seinen Tech-Stack offengelegt – und die Antwort ist erfrischend altmodisch. Ausgelöst wurde der Beitrag durch eine Pitch-Night-Absage mit der Begründung „What do you even need funding for?“. Man ahnt bereits, wohin die Reise geht.
Hanovs Stack besteht aus einem VPS bei Linode oder DigitalOcean für 5 bis 10 Dollar monatlich, einem in Go kompilierten Binary und SQLite mit aktiviertem WAL-Mode als Datenbank. Statt AWS-EKS-Cluster und RDS gibt es ein scp aufs Server, statt Connection Pooling ein PRAGMA journal_mode=WAL. Für Batch-AI-Tasks nutzt er eine gebrauchte RTX 3090 mit 24GB VRAM für 900 Dollar, auf der vLLM läuft – das erinnert an Arvid Kahls GPU-Setup aus Ausgabe 148.
Charmant-zynisch ist sein Copilot-Trick: Microsoft rechne pro Request statt pro Token ab, also schreibe er detaillierte Prompts und lasse den Agent 30 Minuten durch den Codebase laufen – für rund 4 Cent, während „Satya Nadella subventioniert meine Compute-Kosten“. Ob das Preismodell so bleibt, ist eine andere Frage.
Die Kommentare lesen sich wie ein Stimmungsbild der Branche: Ein Nutzer fährt mit Python, SQLite und Ollama einen autonomen Trading-Bot auf einer RTX 4070, ein anderer verweist auf Cloudflare Workers für 5 Dollar. Die Kritiker bringen valide Punkte – Single-Server-Setups skalieren nicht, Security auf einer Maschine ist anspruchsvoller, und spätestens bei Compliance-Anforderungen wird es eng. Passend dazu hatte auch Talk Python kürzlich den Weg zurück zu Hetzner angetreten und dabei 62 Prozent Kosten gespart (Ausgabe 169).
Wie immer lautet mein Fazit – it depends – Pauschalisierungen sind hier nicht gut, aber die Beispiele sind trotzdem hilfreich – ich hab nun mal angefangen, alle Cloud-Exit Stories aus dem Newsletter hier übersichtlich zu verlinken – check es gerne mal aus.
How I run multiple $10K MRR companies on a $20/month tech stack
Schmunzelecke
Jemand hat hier eine Floppy Disk TV Remote gebaut – also eine Art Tonies für Streaming – manche Leute haben zu viel Zeit.
💡 Link Tipps aus der Open Source Welt
Recordly – Polierte Screen Recordings ohne Nachbearbeitung
Recordly ist ein Open-Source Screen Recorder und Editor, der aus dem in Ausgabe 230 vorgestellten OpenScreen hervorgegangen ist und dessen Funktionsumfang deutlich erweitert. Auto-Zooms, Cursor-Polish und gestylte Frames werden direkt beim Export angewendet – kein Motion Designer nötig.
Key Features:
- Auto-Zooms: Automatische Zoom-Vorschläge basierend auf Cursor-Aktivität, plus manuelle Zoom-Regionen auf der Timeline
- Cursor Controls: Smoothing, Motion Blur, Click Bounce, Sway, Loop Mode, macOS-Style Cursor Assets – der Cursor sieht im Export immer poliert aus
- Webcam Overlay: Bubble-Overlay mit Presets, Custom-Positionierung, Zoom-Reaktivität und Spiegelung
- Timeline Editing: Drag & Drop für Zooms, Trims, Speed Regions, Annotations, Audio Regions und Crop
- Frame Styling: Wallpapers, Gradients, Solid Colors, Blur, Padding, Shadows, Rounded Corners, Aspect Ratio Presets
- Projektdateien: .recordly Files speichern Editor-State für späteres Weiterarbeiten
- Extensions & Marketplace: Community-Extensions für Cursor Sounds, Device Frames, Browser Mockups, Wallpapers und mehr
- Export: MP4 und GIF mit Quality/Framerate/Loop-Einstellungen
Cross-Platform: macOS 14+ (native ScreenCaptureKit), Windows 10 Build 19041+ (native WGC), Linux (Electron Capture). Gebaut mit Electron, PixiJS und TypeScript.
Recordly ist im Vergleich zum Ursprungsprojekt OpenScreen ein großer Sprung – das Extension-System, die Webcam-Overlays und die Projektdateien machen es zu einer ernsthaften Screen Studio Alternative. Mit 11.3k Stars und aktivem Development hat Recordly OpenScreen in kurzer Zeit deutlich überholt. Wer also OpenScreen interessant fand, sollte sich Recordly anschauen.
https://github.com/webadderallorg/Recordly
Yamtrack – Self-Hosted Media Tracker für alles
Yamtrack ist ein self-hosted Media Tracker für Filme, Serien, Anime, Manga, Videospiele, Bücher, Comics und Brettspiele – alles in einer App, alles unter eigener Kontrolle (Screenshots zum Tool bei GitHub).
Key Features:
- Breites Tracking: Score, Status, Fortschritt, Rewatches/Rereads, Start-/Enddatum, Notizen. TV-Serien mit individueller Staffel- und Episodenverfolgung
- Tracking History: Jede Aktion wird protokolliert – wann hinzugefügt, gestartet, erneut geschaut etc.
- Kalender: Kommende Releases im Überblick, abonnierbar als iCalendar (.ics) in externen Apps
- Benachrichtigungen: Release-Notifications via Apprise (Discord, Telegram, ntfy, Slack, E-Mail und mehr)
- Media Server Integration: Jellyfin, Plex und Emby tracken automatisch neu geschaute Medien
- Import: Trakt, Simkl, MyAnimeList, AniList, Kitsu – auch als periodischer Auto-Import
- Listen & Multi-User: Persönliche Listen mit Collaboration, individuelle Accounts, OIDC und 100+ Social Provider via django-allauth
- Custom Entries: Eigene Medieneinträge für Nischen-Content, der in keiner API zu finden ist
Deployment via Docker Compose mit SQLite (Standard) oder PostgreSQL. Gebaut mit Django und TailwindCSS. Während es für einzelne Medientypen spezialisierte Tracker gibt (Trakt für Filme/Serien, AniList für Anime), deckt Yamtrack als einzige self-hosted Lösung praktisch alle Medientypen ab. Die Jellyfin/Plex-Integration und die Auto-Imports von bestehenden Diensten machen den Umstieg einfach.
Falls du eine andere Lösung für das Thema hast, mit der zu zufrieden bist – schreib mir gerrne!
https://github.com/FuzzyGrim/Yamtrack
❓ 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: