Willkommen zu allesnurgecloud.com – Ausgabe #215
Tja, am Freitag liefen wieder die OnCall Handy etwas amok – Cloudflare war down und diesmal auch viele große Shopify Shops oder Cloudflare Enterprise Kunden wie aboutyou und mydealz. Passiert den Besten und wir wollen ja schon den schnellen Security Fix und kein Datenverlust, weil man zu spät reagiert hat, oder?
Ansonsten hab ich hier noch nen interessanten Artikel zu „Datacenters in Space“ gefunden – die seien doch keine so gute Idee.
Und hier gibt es noch ein cooles und ausführliches Video mit Linus Torvalds im Kanal von „Linus Tech Tips“ zu „Building the Perfect Linux PC“ – es werden auch viele anderen Fragen geklärt – Android vs. iOS, Git, und auch „What happens to Linux if you die“?
Happy Bootstrapping Podcast
In der aktuellen Podcast Folge 150 spreche ich mit Maruan Faraj von „Finally Freelancing“ über „Mehr verdienen, weniger arbeiten – als Freelancer?“ Provokanter Titel und ich kann die Folge trotzdem sehr empfehlen. Maruan hilft auch vielen Solo-Entwicklern, erfolgreicher zu sein – so hat er schon über 1200 Freelancern geholfen und sich beeindruckende Social Media Präsenzen aufgebaut – hör gerne mal rein in Folge 150 (Spotify / Apple).
Wenn dir die Podcast Folgen 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.
Auf allesnurgecloud.com findest Du vorherige Ausgaben und den RSS-Feed.
Vielen Dank für Dein Interesse und wie immer freue ich mich über Feedback und Weiterempfehlungen.
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:
Cloudflare-Ausfall: React-Security-Fix bringt WAF zu Fall
Am Freitag, den 5. Dezember um 8:47 UTC war Cloudflare für 25 Minuten down – betroffen waren unter anderem sämtliche Shopify-Stores wie snocks.com, aber auch aboutyou.de und mydealz.de lieferten einen 500er Internal Server Error. Mir ist das direkt aufgefallen, da ich zu der Zeit für meinen anstehenden Podcast Gast, Konstantin Singer vom „Digital Detoxing Device“ thezenbox.de recherchiert hatte. Seine Website ist ein Shopify Shop – und auch hier kam der 500er. Die Podcast Aufnahme ging dann auch später los, da mein Aufnahme Tool riverside.fm eben auch Cloudflare im Einsatz hat. Das ist schon alles echt irgendwie ziemlich verzwickt, dass wir dieses eigentlich dezentrale Internet so umgebaut haben.
Cloudflare hatte einen WAF (Web Application Firewall) Change deployed, um die am 3. Dezember gepatchte React Server Components Vulnerability (CVE-2025-55182 / CVE-2025-66478) zu mitigieren. Die Schwachstelle mit CVSS 10.0 erlaubt Remote Code Execution in React Server Functions und betrifft Next.js 15.x, 16.x und 14.3.0-canary.77+. Entdeckt wurde sie von Lachlan Davidson am 29. November, gepatcht am 3. Dezember. Für Next.js 14.x ist der Security Support eigentlich schon eingestellt, hier hat man dann wohl aber aufgrund der Kritikalität eine Ausnahme gemacht – gut so.
Im Cloudflare Blog gibt es weitere Informationen zum Ausfall – da war man mal wieder sehr schnell. Cloudflare erhöhte die WAF-Buffer-Size von 128KB auf 1MB, um React-Apps zu schützen. Eine zweite Änderung sollte ein internes Testing-Tool deaktivieren – diese wurde via Global Configuration System ausgerollt (keine graduelle Rollout). Im FL1 Proxy (Legacy-Code in Lua) triggerte dies eine Lua Exception: attempt to index field 'execute' (a nil value). Nur Kunden mit FL1 Proxy UND Cloudflare Managed Ruleset waren betroffen – der neue FL2 Proxy (Rust) hatte das Problem nicht.
So langsam aber sicher sinkt bestimmt die „Trust Battery“ des ein oder anderen Cloudflare Kunden. Den letzten größeren Ausfall gab es zuletzt am 18. November für mehrere Stunden – ich hatte ausführlich in Ausgabe 212 darüber berichtet. Bei We Manage haben wir diverse Kunden schon alleine wegen der Netzbremse auf BunnyCDN umgezogen und sind damit super zufrieden – es gab hier jedenfalls keinen Ausfall und die Performance aus dem Telekom Netz ist deutlich besser. Natürlich is der Leistungskatalog bei Cloudflare viel umfangreicher und man kann nicht 1:1 migrieren, je nach Use-Case.
Auf der anderen Seite hat Cloudflare genau das gemacht, was es soll und seine Kunden möglichst schnell vor einer Sicherheitslücke geschützt. Dass es hierbei zu einem Ausfall aufgrund der nötigen Implementierung kam ist natürlich sehr ungeschickt – der Aufschrei beim Ausnützen der Sicherheitslücke wäre aber deutlich größer gewesen. Da bin ich dann lieber im Team „Lieber schnell fixen“.
Bist du Cloudflare Kunde und planst eine Migration? Falls ja, wohin?
189 Bugs in einer Woche gefixed bei Google „Fixit Week“
Lalit Maganti, Senior Staff Software Engineer bei Google, beschreibt im verlinkten Blog-Post, wie sein 45-köpfiges Team eine Woche lang sämtliche Roadmap-Arbeit einstellte und sich ausschließlich auf Bug-Fixes konzentrierte. Das Ergebnis: 189 behobene Bugs, im Median 4 Bugs pro Person, ein Einzelner schaffte 12 Fixes. Am Freitag um 16 Uhr war er „genuinely sad that Monday means going back to regular work“.
Die Regeln sind strikt: Keine Meetings, kein Roadmap-Work, hartes 2-Tage-Limit pro Bug. Wer länger braucht, dokumentiert seine Findings und wechselt zum nächsten Issue. Fokus liegt auf kleinen End-User-Bugs und Developer-Productivity: unklare Error Messages die seit zwei Jahren existieren, Performance-Probleme in CI-Pipelines, Feature-Requests aus 2021 die nur einen Tag Implementierung benötigen. Ein konkretes Beispiel: Ein „amalgamated SDK“ wurde in einer Stunde mit AI-Unterstützung implementiert – könnte der Unterschied sein zwischen „use it or not“.
Gamification mit Punktesystem (1/2/4 Punkte nach Aufwand) und Leaderboards motiviert – kritisch: Punkte fließen nicht in Performance Reviews ein, sonst stirbt der „good vibe“. T-Shirts gibt’s für „first bug fix“ oder „most annoying bug“.
LLMs haben den Context-Switching-Overhead massiv reduziert: Copilot liefert schnelle Einstiegspunkte, ein Docs-Update wurde beispielsweise per AI „one-shot“ gefixt. Und hat nun Gemini dann Copilot kontrolliert oder wie stellt man die Qualität sicher?
Ein Ex-Meta-Mitarbeiter berichtet im Gegenzug auf Hacker News, dass Fixit Weeks bei Reality Labs zum Anti-Pattern wurden – Entwickler landeten bewusst „all the possible crap“, um es dann in der Fixit Week zu „fixen“.
Fixit Weeks sind also kein Ersatz für gute Engineering-Kultur. Auf der anderen Seite glaube ich fest daran, dass viele Devs wissen, welche Leichen im Keller liegen – man bekommt nur eben keine Zeit dafür, diese dann auch zu fixen. So eine ganze Woche „Fixit Week“ ist sicherlich mal ein spannendes Experiment für jede Organisation, braucht aber auch etwas Planung und Vorbereitung.
Hast du schon mal sowas gemacht und wie hat es funktioniert?
We stopped roadmap work for a week and fixed 189 bugs
Anzeige
Hier könnte Deine Werbung stehen
Du möchtest Deine Firma, angebotene Dienstleistungen & Services oder Dein SaaS Produkt hier im Newsletter vorstellen?
Du suchst neue Mitarbeiter und möchtest diese direkt erreichen?
Erreiche über 1400 Cloud und Open-Source Enthusiasten direkt per E-Mail und im RSS Feed. Dazu kommen 1000+ Impressions im LinkedIn Artikel des Newsletters.
Die Preise beginnen ab 150€ pro Ausgabe – bei Interesse antworte mir direkt auf den Newsletter oder kontaktiere mich über LinkedIn ich schreib dann auch ganz schnell zurück.
Jetzt Werbung anfragen (und Freitags deployen)
489 Millionen Requests/Minute: Shopify’s Black Friday Rekord
Shopify-CEO Tobi Lütke verkündete am 2. Dezember die Black Friday Cyber Monday Zahlen: 14,6 Milliarden Dollar Merchants-Umsatz, ein Plus von 27% gegenüber Vorjahr. 81 Millionen Käufer kauften bei Shopify-Brands, 15.800+ Unternehmer machten ihren ersten Sale.
Die technischen Zahlen sind beeindruckend: Shopify’s Edge verarbeitete durchschnittlich 312 Millionen Requests pro Minute, im Peak waren es 489 Millionen Requests/Minute. Die globale Kubernetes-Infrastruktur lief mit über 3,18 Millionen CPU Cores. Die MySQL 8 Datenbank-Cluster verarbeitete 53,8 Millionen Queries pro Sekunde – insgesamt 14,8 Billionen DB Queries und 1,75 Billionen Writes. Shopify verarbeitete 90 Petabyte Daten und 2,2 Billionen Edge Requests.
Die CDN (powered by Cloudflare) lieferte 183 Millionen Requests/Minute mit 97,8% Cache Hit Rate. Flink verarbeitete 150 MB/s, die Streaming-Analytics-Latenz verbesserte sich durch Migration auf Flink SQL um Faktor 103 seit BFCM 2024. Im Peak liefen 23,2 Millionen Async Jobs pro Minute. Shopify loggte 11TB Logs pro Minute im Peak . das machen sie in ClickHouse, wir fleissige Allesnurgecloud Leser bestimmt wissen.
Allerdings bestätigte Tobi auch, dass Admin-Interfaces zeitweise nicht erreichbar waren – die Online Stores blieben aber verfügbar und verkauften durchgehend. Ich hatte mir den Status Entry dazu eigentlich für „Die Kochen auch nur mit Wasser“ section gebookmarked, aber irgendwie sind alte Einträge hier nun nicht mehr aufrufbar oder ich bin einfach zu blöd.
Wie dem auch sei – total beeindruckende Zahlen!
This Black Friday Cyber Monday, the scale of global commerce surged
9 Monate Vorbereitung: Wie Shopify den Traffic-Rekord meisterte
Was hinter diesen Zahlen steckt, dokumentiert Shopify in einem Engineering-Blog-Post: 9 Monate Vorbereitung, 5 große Scale Tests von April bis Oktober, Tests so massiv, dass sie nachts liefen und mit YouTube koordiniert wurden. Das Ziel: 150% der vorjährigen BFCM-Last simulieren und jeden Bottleneck fixen, bevor Merchants ihn erleben.
Die Vorbereitung startete schon im März mit drei parallelen Workstreams:
- Capacity Planning (Traffic-Modellierung und Cloud-Provider-Koordination)
- Infrastructure Roadmap (Tech-Stack-Review und Upgrades)
- Risk Assessments („What Could Go Wrong“-Übungen).
Aus letzteren entstand die Resiliency Matrix – eine zentrale Dokumentation aller Vulnerabilities, Incident-Response-Prozeduren und Fixes, die das ganze Jahr über aktualisiert wird.
Game Days und Chaos Engineering liefen ab Frühjahr: kontrollierte Fault-Injection in Produktions-Systeme, Cross-System-Disaster Simulationen für kritische User-Journeys (Checkout, Payment, Order Creation, Fulfillment). Das Load-Testing-Tool Genghis simulierte User-Behavior, während Toxiproxy (ein Open-Source-Framework von Shopify) zufällige Netzwerk Fehler injizierte. Die Tests liefen parallel aus drei GCP-Regionen (us-central, us-east, europe-west4).
Die besondere Herausforderung 2025: Die neue Analytics-Plattform (2024 komplett neu aufgebaut mit neuen ETL-Pipelines und APIs) hatte noch nie BFCM-Traffic gesehen. Die ETL-Pipelines liefen durch BFCM 2024, die API-Layer starteten aber erst danach. Die Game Days deckten auf: Kafka benötigte mehr Partitions, der API-Layer benötigte Memory-Optimierung und diverse Connection-Timeouts mussten getunt werden.
Die fünf Skalierungs-Tests simulierten dann den kompletten Traffic Flow durch alle beteiligten Services und wurden schrittweise der echten Workload angenähert: Test 1-2 validierten Baseline-Performance, Test 3-5 erhöhten die Last auf 2025-Projektionen. Test 4 erreichte 146 Millionen Requests/Minute und 80.000+ Checkouts/Minute. Der letzte Test simulierte p99-Traffic bei 200 Millionen RPM. Jeder Test deckte Probleme auf, die nur bei diesen Tests sichtbar wurden: Checkout-Queue-Backups, unplanned Failovers, Rate-Limit-Probleme bei authenticated Checkouts.
Beeindruckend, wie man sich in diesem Scale mit solchen Themen beschäftigen darf. Ich frag mich ja, was alleine das Testing an Infrastruktur und Personal in der Durchführung gekostet hat. Hat sich ja aber offensichtlich mehr als gelohnt die ganze Aktion.
How we prepare Shopify for BFCM
8-Stunden-Mythos: Was Wissensarbeiter wirklich leisten können
Eine vielleicht unbequeme Wahrheit über Produktivität liefert Ashley Janssen in einem aktuellen Blogartikel. Sie analysiert darin, warum Wissensarbeiter typischerweise nur 5-6 Stunden täglich wirklich produktiv sind – und warum das völlig normal sei. Die Produktivitätsberaterin räumt mit dem Mythos des 8-Stunden-Arbeitstages auf, der aus der industriellen Revolution stammt und für Fabrikarbeit konzipiert wurde, nicht für kreative Wissensarbeit.
Die wissenschaftlichen Fakten sind eindeutig: Das menschliche Gehirn kann nur 3-5 Stunden Deep Focus pro Tag aufrechterhalten, danach setzt mentale Ermüdung ein. Hinzu kommen natürliche Energiezyklen, die über den Tag variieren. Jede Unterbrechung – Slack, E-Mail, spontane Meetings – kostet zusätzlich mentale Energie und zwingt zum aufwändigen Kontext-Wechsel. Ein Problem, das viele aus dem Arbeitsalltag kennen dürften.
Für Führungskräfte formuliert Janssen eine klare Empfehlung: Weg von der Anwesenheitskultur, hin zu ergebnisorientierten Deliverables. Flexible Arbeitszeiten und Remote-Optionen ermöglichen es Mitarbeitenden, ihre produktiven Phasen optimal zu nutzen. Die Gleichung „mehr Stunden = mehr Output“ gilt für Wissensarbeit schlicht nicht – eine Erkenntnis, die Unternehmen wie GitLab oder Automattic längst in ihren ROWE-Modellen umsetzen, wie ich in Ausgabe 175 bereits beschrieben hatte.
Falls du empfehlenswerte Bücher zum Thema „Results only Work Environment“ suchst – ich hatte hierzu mal „Morgen komm ich später rein“ gelesen und fand es cool – „Drive – Was sie wirklich motiviert“ von Daniel Pink steht noch ungelesen hier und die initiale Idee zum Thema ROWE kommt von Cali Ressler und Jody Thompson in „Why Work Sucks and How to Fix it“ (Alle Links Affiliate Links).
Falls du noch Input, Links oder Bücher zum Thema hast – gerne her damit.
Why Are You Productive For „Only“ 5-6 Hours Each Day?
GitHub Exodus: Zig und Dillo migrieren zu Codeberg und Self-Hosting
Binnen einer Woche haben zwei Open-Source-Projekte ihre GitHub-Abkehr verkündet: Die Programmiersprache Zig wechselt zu Codeberg, der Dillo-Browser zu Self-Hosting. Beide Projekte nennen nahezu identische Gründe.
Zig-Gründer Andrew Kelley rechnet nach 10 Jahren auf GitHub schonungslos ab: Die Engineering-Exzellenz sei verfallen, die Plattform wurde zu einem „bloated, buggy JavaScript framework“. GitHub Actions betreibt mittlerweile „vibe-scheduling“ – Jobs werden scheinbar zufällig ausgeführt. Nach dem CEO-Statement „embrace AI or get out“ wurde Copilot aggressiv gepusht, was Zig’s strikte No-LLM/No-AI-Policy wiederholt verletzte. Das Repository ist ab sofort read-only, neue Issues starten bei #30000 auf Codeberg.
Dillo-Maintainer Rodrigo Arias Mallo migriert den Browser zu dillo-browser.org mit Self-Hosting. Das Problem: GitHub funktioniert ohne JavaScript nicht mehr – ein Browser-Projekt kann seine eigene Forge nicht nutzen. Die Lösung: cgit (C-basiert, kein JavaScript nötig) für Git-Frontend, selbst entwickeltes buggy (Markdown-basierte Bug-Tracker in Git) für Issues. Mirrors auf Codeberg und Sourcehut sichern gegen Single-Point-of-Failure.
Das GitHub Sponsors Problem trifft allerdings beide: Zig verliert eine große Einnahmequelle, bittet Spender zu Every.org zu wechseln. Devon Zuegel, die GitHub Sponsors aufbaute, ist weg – das Produkt wird vernachlässigt. Ich nutze GitHub Sponsors schon, da man einfach spenden kann und eine zentrale Abrechnung bekommt.
Migrating from GitHub to Codeberg
Engineering Kiosk Podcast „Yak Shaving“ anschaulich erklärt
Yak Shaving – wenn Entwickler vom Kurs abkommen: Im Adventskalender des Engineering Kiosk Podcasts erklärt Podcast Host Andy Grunwald ein Phänomen, das jeder Entwickler kennt: Du willst einen Bug fixen, aber erst muss das Plugin aktualisiert werden, dann die Config angepasst, dann die Test-Library erneuert, oder die CI/CD Pipeline gefixed werden – und am Ende des Tages hast du keine Zeile am eigentlichen Problem geändert. Das ist Yak Shaving.
Der Begriff stammt aus den 90er Jahren vom MIT AI Lab, inspiriert von der Comedy-Serie „Ren & Stimpy“. Er beschreibt eine Kette von scheinbar legitimen Nebenaufgaben, die vom eigentlichen Ziel ablenken. Besonders gefährlich wird es als Gruppeneffekt: Plötzlich arbeitet ein ganzes Team zwei Wochen an Infrastruktur-Aufräumarbeiten statt am Feature-Launch.
Praktische Gegenmittel laut Andy: Klares Ziel und Scope definieren, eine „Not-to-do-Liste“ führen, Timeboxing einsetzen und Kollegen drüberschauen lassen. Interessant auch die Abgrenzung zum Bikeshedding – während Yak Shaving individuelle Tunnelvision beschreibt, ist Bikeshedding die Gruppendiskussion über triviale Details – ha, das machen wir doch alle gern.
Der Engineering Kiosk Adventskalender liefert täglich kurze Tech-Episoden – auch ich bin mit einer Folge zum Thema „Trust Battery“ dabei – ich weiß nur noch nicht wann die erscheint, bestimmt bald 🙂
Engineering Kiosk Podcast Adventskalender: #224 Yak Shaving
Wie Datadog 100 Billionen Events in Millisekunden durchsucht
In einem ausführlichen Engineering-Artikel beschreibt Sami Tabet die Architektur von Husky, Datadogs dritter Generation ihres Event Stores. Die Zahlen sind beeindruckend: 100 Billionen Events und Milliarden Queries täglich – mit interaktiver Performance im Millisekundenbereich.
Die technische Architektur besteht aus vier Hauptkomponenten: Query Planner, Query Orchestrator, Metadata Service und Reader Service. Besonders clever ist das mehrstufige Caching: Der Result Cache erreicht 80% Hit-Rate, der Blob Range Cache liegt bei 70%. Der Predicate Cache trifft nur in 3% der Fälle, spart aber pro Hit das 11-fache an CPU-Arbeit.
Das Ergebnis des Prunings ist spektakulär: Von 1.000 Fragment-Queries müssen nur 34 echte Daten lesen, lediglich 4 treffen auf Blob Storage. Techniken wie Row Groups mit Lazy Evaluation, Zone-Map-Pruning und Text-Search via Posting Lists machen’s möglich. Shuffle Sharding sorgt für Tenant-Isolation ohne Ressourcenverschwendung. Nun hast du das Bingo aber auf jeden Fall als erster am Start, oder?
Für die Zukunft setzt Datadog übrigens auf Apache Arrow, Parquet und DataFusion – der „Deconstructed Database“-Trend, den auch ClickHouse mit dem ClickStack-Projekt verfolgt.
Inside Husky’s query engine: Real-time access to 100 trillion events
Schmunzelecke
„Major AI conference flooded with peer reviews written fully by AI“ – treffender kann man eine Schlagzeile wohl nicht formulieren – zum Artikel bei nature.com
„Google Antigravity just deleted the contents of my whole drive“ – Tja, man sollte halt nicht alles eins zu eins übernehmen – Infos bei Reddit und hier das Video dazu bei YouTube.
💡 Link Tipps aus der Open Source Welt
Uncloud – leichtgewichtiges clustering und container orchestration tool
Uncloud ist ein leichtgewichtiges Clustering- und Container-Orchestrierung-Tool, das Web-Apps über Cloud-VMs und Bare-Metal-Server ohne komplexen Cluster-Management-Overhead verwaltet. Es erstellt ein sicheres WireGuard-Mesh-Netzwerk zwischen Docker-Hosts und bietet automatische Service Discovery, Load Balancing und HTTPS-Ingress.
Features:
- Keine Control Plane: Vollständig dezentrales Design ohne Single Point of Failure (das finde ich super interessant)
- Docker Compose Native: Nutzt vertrautes Docker Compose Format ohne neue DSL
- Zero-Downtime Deployments: Rolling Updates ohne Service-Unterbrechung
- Unregistry Integration: Docker Images direkt auf Maschinen pushen ohne externe Registry
- WireGuard Mesh: Automatisches privates Netzwerk mit Peer Discovery und NAT Traversal
- Service Discovery: Eingebauter DNS-Server für Container-zu-Container-Kommunikation
- Persistent Storage: Docker Volumes über mehrere Maschinen verwalten
- Managed DNS: Automatische
*.id.cluster.uncloud.runDNS-Records - Auto-HTTPS: Integrierter Caddy Proxy mit Let’s Encrypt Zertifikaten
- Imperative CLI: Docker-ähnliche Commands statt deklarative State-Reconciliation
Jede Maschine hält eine synchronisierte Kopie des Cluster-States via Peer-to-Peer-Kommunikation. Der Cluster bleibt funktionsfähig, selbst wenn einzelne Maschinen offline gehen (Schaubild bei GitHub).
Zielgruppe sind Entwickler, die Self-Hosted-Infrastruktur ohne die operative Komplexität von Kubernetes wollen. Uncloud kombiniert die Einfachheit von Docker mit der Power von Multi-Machine-Deployments.
Mehr Infos und eine Demo findest du auf der uncloud website.
https://github.com/psviderski/uncloud
Fizzy – Kanban neu gedacht von 37signals
Fizzy ist ein modernes Kanban-Tool aus dem Hause 37signals (Basecamp, HEY), das sich bewusst gegen den Feature-Bloat etablierter Tools positioniert. Jason Fried und sein Team haben ein schnelles, fokussiertes Issue-Tracking-System entwickelt, das 1000 Karten kostenlos bietet.
Features:
- 1000 Karten kostenlos: Keine Zeitlimits, unbegrenzte Nutzer
- Auto-Close: Automatisches Pruning alter Karten
- Webhooks: Integration mit Slack, Campfire und anderen Tools
- Public Boards: Öffentliche Boards für externe Stakeholder
- Notification Stack: Übersichtliche Benachrichtigungs-Verwaltung
- Stamps: Wer hat was wann eingereicht
- Open Source: Vollständig selbst-hostbar via GitHub
- Kamal Deployment: Self-Hosting mit 37signals‘ eigenem Deployment-Tool
Pricing:
- Kostenlos: 1000 Karten, 1GB Storage
- $20/Monat: Unbegrenzte Karten + Nutzer, 5GB Storage
- Zusätzlicher Storage: 50GB Increments
Fizzy ist eine bewusste Gegenbewegung zu überladenen Tools wie Jira („charging by the migraine“) oder dem aufgeblähten Trello. Keine KI-Features, dafür Geschwindigkeit und klares Design.
Self-Hosting: Als Open-Source-Projekt kann Fizzy komplett selbst betrieben werden. Die flexible Lizenz erlaubt eigene Anpassungen und Contributions via GitHub PRs.
Die Projekt und die UI ist typisch 37signals – radikal vereinfacht, opinionated Design, faire Preisgestaltung. Für Teams, die ein unkompliziertes Kanban ohne Enterprise-Overhead suchen, definitiv einen Blick wert.
❓ 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: