Eine Heroku-Rechnung von 3.000 US-Dollar pro Monat durch einen Server für 55 US-Dollar pro Monat ersetzen

• Die gemeinnützige Jobplattform Idealist migrierte auf einen günstigen dedizierten Server, um das Problem der teuren Staging-Umgebungen bei Heroku zu lösen
• Bei Heroku führte das pro Umgebung abgerechnete Modell dazu, dass jede Staging-Umgebung Kosten von rund 500 US-Dollar pro Monat verursachte
• Als Ersatz wurden mehrere Umgebungen auf einem einzigen Hetzner-CCX33-Server (55 US-Dollar/Monat) eingerichtet, wobei mit Disco die gleiche git push- und Automatisierungs-Erfahrung wie bei Heroku erhalten blieb
• Auf einem einzelnen Server laufen 6 Staging-Umgebungen stabil; die CPU-Auslastung liegt bei 2 %, der Speicherverbrauch bei 14 von 32 GB und bietet damit viel Spielraum
• Dadurch wandelten sich Staging-Umgebungen von einem „Kostenfaktor“ zu einer „frei erzeugbaren Ressource“, was die Experimentier- und Deployment-Kultur des Entwicklungsteams deutlich verbesserte

---

Praxisbericht: Eine praktische Strategie zur Senkung der Heroku-Kosten

Das Problem: Eine Staging-Umgebung für 500 US-Dollar im Monat

• Idealist.org ist eine große gemeinnützige Jobplattform mit mehreren Millionen Besuchen pro Monat, für die eine Staging-Umgebung, die der Produktionsumgebung nahezu entspricht, unverzichtbar ist
• Bei Heroku lagen die Kosten für eine einzelne Staging-Umgebung mit den benötigten Add-ons wie Web- und Worker-Dynos sowie Postgres bei etwa 500 US-Dollar pro Monat
• Schon das Vorhalten von nur zwei Umgebungen, dev und main, verursachte fixe Kosten von über 1.000 US-Dollar
• Herokus Preismodell ist ein Abrechnungsmodell pro Umgebung; selbst bei weniger Dynos ist das Einsparpotenzial gering, und mit wachsender Zahl von Anwendungen steigen die Kosten stark an

Das Experiment: Migration auf einen einzelnen Server

• Um die Kosten ideal zu senken, begann man ein Experiment mit einem gemieteten einzelnen Hetzner-CCX33-Server (55 US-Dollar/Monat)
• Mit der Disco-Lösung wurde das bestehende git push-Deployment-Modell von Heroku unverändert auf den Server übertragen
• Alle Staging-Umgebungen nutzen dieselbe gemeinsame Postgres-Instanz auf dem Server, wodurch die Kosten für Managed Databases erheblich sinken
• Aus Testperspektive ist das passend, weil sich getrennte Datenbanken pro Entwickler einfach zurücksetzen lassen

Warum Disco statt Docker Compose?

• Allein docker-compose up auf einem Server bietet noch keine ausreichend gute Developer Experience
• Disco bietet unter anderem folgende Vorteile
  • denselben git push-Deployment-Prozess wie Heroku
  • automatische Zero-Downtime-Deployments für alle Deployments
  • automatische Ausstellung und Erneuerung von SSL-Zertifikaten für branch-spezifische URLs
  • eine intuitive Web-UI für Logs und Umgebungsverwaltung
• So bleibt der Komfort für Entwickler erhalten, ohne eine eigene Automatisierung für das Deployment-Management aufbauen und pflegen zu müssen

Explosion der Staging-Umgebungen und effiziente Server-Ressourcennutzung

• Mit Disco wurde die Skalierung von Staging-Umgebungen äußerst einfach
• Auf einem einzelnen Server werden gleichzeitig unter anderem folgende Umgebungen betrieben
  • der Main-Branch
  • der feature-freeze-Branch
  • temporäre Throwaway-Umgebungen für PRs
  • langfristige Umgebungen für die Entwicklung großer Features
• Insgesamt laufen 6 unabhängige Staging-Umgebungen ohne Probleme
• Bei Heroku würde das 3.000 US-Dollar pro Monat kosten, bei Hetzner verbraucht dieses kostengünstige Setup dagegen nur 2 % CPU und 14 GB RAM (von 32 GB)

Trade-offs und praktische Überlegungen

• Es ist keine vollständige Alternative; einige operative Aufwände kommen hinzu
• Infrastrukturarbeiten wie DNS- oder CDN-Konfiguration für neue Umgebungen sind nicht automatisiert
• Es entsteht Betriebsverantwortung für Server-Monitoring, Sicherheitsupdates und Reaktionen auf Ausfälle
• Da Hetzner nur eingeschränkt US-Regionen anbietet, kann es für Produktionsservices mit US-Zielgruppe ungeeignet sein
• Im Fall eines Serverausfalls besteht ein Verfügbarkeits-Trade-off, da man eine Neuinstallation in Kauf nimmt
• Um die Anwendung an Docker Networking anzupassen, war etwa ein Tag Engineering-Aufwand nötig

Erkenntnisse und Veränderungen

• Nach mehr als sechs Monaten Betrieb hat sich diese Infrastruktur als dauerhafte Struktur etabliert
• Die wichtigste Veränderung ist nicht nur die Kostensenkung, sondern dass Staging-Umgebungen nun als reichlich vorhandene und frei nutzbare Ressource wahrgenommen werden
• Entwickler können nun ohne Abstimmung oder Kostensorgen bei Bedarf frei Umgebungen pro Pull Request erstellen
• Im Team entstand die Erkenntnis, dass nicht nur die Kosten belastend waren, sondern auch das Zögern bei der Nutzung selbst der eigentliche Verlust war
  • „Die finanziellen Hürden haben Entwicklungsgeschwindigkeit und Experimente eingeschränkt“

[GN⁺]

Hacker-News-Kommentare

• Im htop-Screenshot fiel auf, dass kein Swap vorhanden ist, daher wird empfohlen, earlyoom zu aktivieren, um einen kompletten Serverausfall zu verhindern, falls ein Dienst ungewöhnlich viel Speicher frisst; der OOM-Killer des Linux-Kernels greift meist zu spät ein. Man kann auch zram aktivieren, den RAM komprimieren und so wie ein Profi überprovisionieren. Lang laufende Software verursacht häufig Memory Leaks, und Komprimierung ist dabei recht effizient. In einem gist ist zusammengefasst, wie man das per Ansible auf einem Hetzner-Bare-Metal-Server umsetzt; in VMs funktioniert es genauso.

  • Stimme ich überhaupt nicht zu. Sobald Swap benutzt wird, bekommen die meisten Apps ernsthafte Probleme. Das ist allgemein bekannt, und auch AWS-EC2-Instanzen haben Swap standardmäßig deaktiviert. Klar, AWS will auch mehr RAM verkaufen, aber Swap passt nicht mehr zu heutigen Erwartungen. In den 90ern wartete man vielleicht noch 2–3 Sekunden auf einen Klick, heute denkt man bei fehlender Reaktion sofort, das System sei tot, und startet direkt neu.

  • Eine weitere Alternative ist, mehr Speicher hinzuzufügen und oom_score pro App anzupassen, sodass unwichtige Apps eine höhere Kill-Gewichtung und wichtige Apps eine negative Gewichtung bekommen. OpenSSH hat zum Beispiel bereits oom_score_adj=-1000. Ebenfalls sehr nützlich ist es, auf Staging-/Production-Servern Overcommit faktisch zu deaktivieren. Je nach RAM-Größe werden min_free- und Reserve-Werte anhand von Formeln berechnet und gesetzt. Das hat sich in der Praxis bewährt, bei über 50.000 physischen Servern über mehr als 10 Jahre hinweg komplett ohne Swap. OOM trat nur auf, wenn bei einem Code-Deployment der Speicherbedarf falsch kalkuliert wurde. Dasselbe gilt, wenn man Best Practices in Java nicht befolgt, aber das wäre eine längere Geschichte. Man kann auch per cgroup Speicherlimits pro Anwendung setzen, aber die Erklärung wird ausgelassen. Wenn es sich um einen vollständig In-Memory-Server ohne Schreibbedarf auf Disk handelt, wird auch empfohlen, OOM grundsätzlich zu verhindern und stattdessen automatisches Self-Healing zu nutzen. Es ist außerdem nützlich, dem System genug Zeit zu geben, Crash-Meldungen per DRAC/iLO zu erfassen, und Panic-Reboot-Einstellungen wie kernel.panic, vm.panic_on_oom usw. zu setzen. Nebenbei kann das in NFS-diskless-Systemen bei Störungen auch absichtlich als Trigger für einen Neustart der gesamten Farm verwendet werden.

  • Danke für die guten Infos. Ich steuere derzeit per Systemlimits (systemd) über RAM-Schwellenwerte, frage mich aber, ob earlyoom die bessere Wahl ist, um zu verhindern, dass die ganze Instanz durch einen aus dem Ruder gelaufenen Prozess unbenutzbar wird.

  • Für den Notfall halte ich es für eine gute Idee, eine sehr kleine Menge Swap vorzuhalten, zum Beispiel 1 GB.

  • Ich habe seit 2010 keinen Swap mehr verwendet.

• Gestern habe ich einen ähnlichen Beitrag von Nate Berkopec über Rails-Performance gesehen, in dem es hieß, Heroku sei gemessen an der Performance 25- bis 50-mal teurer. Es wirkt wirklich so, als hätte man keinerlei Interesse an Preiswettbewerb. Wenn sie stattdessen einfach wie Sidekiq den gesamten Stack zu einem vernünftigen Preis lizenzieren würden, wäre das selbst mit separat betriebener Hardware deutlich besser. Dass ein Dyno mit 1 GB RAM im Jahr 2025 50 $ kostet, ist fast schon Diebstahl. Vor allem, weil eine Standard-Rails-App weder deutlich größere Ressourcenschwankungen hat als früher noch weniger effizient geworden ist — eher im Gegenteil. Trotzdem sind die Preise gestiegen und die Qualität gesunken. Es ist fast lächerlich, dass so viele Entwickler ihre Apps für mehrere Hundert Dollar pro Monat auf Heroku betreiben und dabei Hardware nutzen, die langsamer ist als ihr eigenes MacBook für die Entwicklung. Letztlich folgt das demselben Trend wie vieles andere heute: Statt ein gutes Produkt zu einem vernünftigen Preis für die breite Masse anzubieten, konzentriert man sich nur noch auf die zahlungskräftigste Spitzengruppe und erhöht die Preise.

  • Es geht nicht nur um Preiserhöhungen. Ich glaube, Heroku und Cloud-Anbieter profitieren vom psychologischen Ankereffekt bei Preisen. Nutzer setzen zu Beginn einen Preisanker und passen ihre Erwartungen danach nur noch linear an. Die tatsächliche Rechenleistung der Hardware verbessert sich aber exponentiell, während Nutzer das nur linear wahrnehmen. Herokus Preise haben sich seit mindestens sieben Jahren kaum verändert, die Hardware dagegen enorm. Deshalb fühlt es sich wie Betrug an — tatsächlich vergleicht man aber den Referenzpunkt von 2025 mit Preisen aus der Mitte der 2010er. Große Cloud-Anbieter bauen Hürden ein, etwa durch das Freischalten neuer Hardwareleistung oder SKU-Updates. Heroku hatte keinen solchen Wettbewerbsdruck und hielt die Preise konstant, und solche Beiträge erscheinen immer wieder, sobald neue Ingenieure die Entwicklung der Hardwareleistung am eigenen Leib spüren.

  • Es wurde gesagt, ein Dyno mit 1 GB RAM für 50 $ sei Diebstahl, aber AWS ist auch nicht viel besser. Für 50 $ pro Monat bekommt man ein m7a.medium mit 1 vCPU und 4 GB RAM. Das ist mehr RAM, aber man versteht trotzdem, warum AWS so viel Geld einsammelt.

  • Ich teile die Meinung, dass es gut wäre, wenn es wie bei Sidekiq ein Modell gäbe, bei dem der komplette Software-Stack zu einem vernünftigen Preis lizenziert wird. Deshalb haben wir canine.sh als Open Source veröffentlicht. Wir fanden, dass PaaS-Anbieter keinen Grund haben sollten, auf eine Cloud mit ohnehin schon Aufschlag noch einmal übermäßige Margen aufzuschlagen.

  • Das ist ein bisschen so, als würde man sagen, der Ölwechsel in der Werkstatt oder das Steak im Restaurant sei günstiger, wenn man es selbst macht.

• Die Cloud lässt einen vergessen, wie viel sich mit einem einzigen Server machen lässt. Schon eine Staging-Umgebung in einer teuren Cloud zu betreiben, wirkt unverständlich, aber die Cloud ist heute so komplex mit vielen verflochtenen Komponenten, dass man den Bedarf daran dennoch nachvollziehen kann.

  • Mehreren Entwicklern die Cloud-Grundlagen beizubringen und ein paar Cloud-Experten zu haben, ist für eine ganze Weile ziemlich kosteneffektiv. Wenn Staging und Produktion ähnlich aufgebaut sind, entdeckt man Fehler auch schneller. Später zahlt man dann mehr an Cloud-Kosten als an Personalkosten, und ab diesem Punkt bringt ein Cloud-Ausstieg wirklich einen Vorteil. Ich denke, irgendwann überschreiten die Kosten eines selbst betriebenen Setups zwar Team- und Hardwarekosten, aber genau dann lohnt sich der Umstieg auf eigene Server.

  • Die Cloud hat wohl dazu geführt, dass Entwickler regelrecht Angst vor Linux-Servern selbst bekommen haben. Ich denke, ein Großteil der Marge ist der Preis für diese Unsicherheit. Dabei ist Self-Hosting in Wirklichkeit einfach und macht Spaß. Ich fand Heroku oder Vercel nie besonders attraktiv, und ich glaube, es gibt kaum eine bessere Erfahrung, als von Anfang an selbst einen Server aufzusetzen. Ich würde jedem Entwickler empfehlen, das einmal selbst auszuprobieren.

  • Es ist sehr hilfreich, die Produktionsumgebung möglichst vollständig nachzubilden. Wenn der Deployment-Prozess ähnlich ist, spart das Zeit, und man testet unter Bedingungen, die der echten Produktion viel näher kommen.

  • Darauf basierend könnte man eine Lernplattform für Infrastruktur bauen: Man bekommt in der Cloud bestimmte Ressourcen, muss sie für eine vorgegebene Last passend konfigurieren und kann dann Performance-Scores mit anderen vergleichen.

  • Um 2006 herum war die kleinste AWS-Maschine etwa so groß wie ein ordentlicher Entwicklungs-Desktop, und man musste sie über zwei Jahre mieten, damit sich das lohnte. Heute liegen AWS-Maschinen eher auf dem Niveau eines Mobiltelefons oder billigen Laptops, und schon nach 3–6 Monaten Miete wäre der Kauf der Hardware günstiger. Wenn man nicht 75 % Rabatt bekommt, spart On-Premises gegenüber der Cloud sowohl Personal als auch Kosten.

• Hallo, ich entwickle zusammen mit meinem Freund Antoine Leclair ein Open-Source-PaaS namens Disco. Momentan wird viel über Self-Hosting und den Ausstieg aus der Cloud diskutiert. Fragen dazu sind jederzeit willkommen.

  • Noch beeindruckender wird die Aussage „die Serverressourcennutzung war sehr gering“, wenn man bedenkt, dass die Load Average in htop pro CPU-Kern gilt. Bei 8 Kernen entspricht eine Load Average von 0,1 zum Beispiel nur etwa 1,25 % der gesamten CPU-Kapazität. Hat Spaß gemacht, den Blog zu lesen; durch solche Muster nehme ich selbst viel mit.

  • Mich würde interessieren, was Disco gegenüber Tools wie Coolify konkret zusätzlich bietet. Ich hoste die meisten Dienste auf einem Hetzner-VPS, daher würde ich gern wissen, worin die besonderen Stärken von Disco liegen.

• Wir hatten bei Hack Club eine ähnliche Erfahrung. Unsere Non-Profit-Organisation konzentriert sich darauf, Schülern den Einstieg in Coding und Elektronik zu ermöglichen. Früher nutzten wir Heroku, aber nicht nur die Kosten waren ein Problem — man begann sich auch zu fragen, ob diese kleinen Utility-Apps wirklich 15 $ im Monat wert sind. Dieses Jahr haben wir mit Coolify auf Self-Hosting umgestellt und betreiben jetzt 300 Dienste auf einem einzigen 300-$-pro-Monat-Server von Hetzner. Dadurch konnten wir viel mehr Code deployen. Die wichtigste Erkenntnis war: Wenn man nicht 99,99 %, sondern nur 99 % Uptime braucht, wird die Welt plötzlich viel größer. Die meisten Developer-Tools sind auf 99,99 % fixiert, aber wenn 99 % genügen, kann man sehr effizient arbeiten. Disco interessiert mich jetzt auch, ich werde es auf jeden Fall ausprobieren.

  • Danke, und wenn es Fragen zu Disco gibt, sind Fragen jederzeit über Discord willkommen. Es gibt zwei ähnliche Beispiele: In einer Bootcamp-/Entwicklerschule in Puerto Rico wurden die Abschlussprojekte der Schüler alle auf einem einzigen VPS deployt, und im Recurse Center hostet man 75 Webprojekte auf einem einzelnen Raspberry Pi (Link).

  • Und wenn man wirklich 99,99 % braucht, sollte man meiner Meinung nach gerade die Hyperscaler meiden; der jüngste mehrstündige AWS-Ausfall ist ein gutes Beispiel dafür.

  • 300 Stück? Ich würde gern wissen, welche Aufgaben die einzelnen Dienste jeweils haben.

• Angesichts der aktuellen Lage wirkt Self-Hosting zwar wirklich attraktiv, aber ich möchte noch etwas zum Text selbst anmerken. Dieser Beitrag wirkt stark von AI überarbeitet, und insbesondere der Abschnitt „Bridging the Gap: Why Not Just Docker Compose?“ ist eine 1:1-Kopie von „Powerful simplicity“ auf der Produkt-Landingpage von Disco. Dieser Blogpost ist außerdem die einzige Case Study, die aktuell auf deren Hauptseite gezeigt wird.

  • Das ist völlig richtig. Ich würde gern drei Belege dafür anführen (Scherz), aber unsere Bibliothek ist Open Source und wir sind stolz darauf, dass Idealist Kosten gespart hat. Wenn Stolz schon als Werbung gilt, dann bin ich eben gern stolz.

  • Du sagst, Marketingtexte seien ein Problem — warum genau siehst du das so? Ist das laut Hacker-News-Richtlinien verboten, oder meinst du, jede Form von Marketing sollte gekennzeichnet werden? Es gibt doch kaum Texte auf der Welt, die gar kein Marketing sind.

  • In einem Marketing-Blogpost über Preiswettbewerb zu schreiben, gleichzeitig aber auf der eigenen Website keinen Preis offenzulegen und stattdessen nur Meeting-Buchungen anzubieten, ist für mich das größte Red Flag überhaupt.

  • Ich habe auch sofort nach dem Erlösmodell gesucht, hatte aber nur den Eindruck, dass es wohl bald veröffentlicht wird.

  • Das ist nicht das erste Mal, dass ein Beitrag Marketing enthält, und ich frage mich, was genau an Marketing über fallbasierte Artikel problematisch sein soll. Es war ein vergleichsweise zurückhaltendes Beispiel, und auch mit Marketingcharakter fand ich es interessant und nützlich.

• Herokus Preise sind wirklich verrückt. Ich war vor etwa zehn Jahren bei einem Startup, das monatlich über 10.000 $ dafür ausgab, einen Dienst zu betreiben, der lediglich QR-Codes als HTML-Tabelle erzeugte und in E-Mails anzeigte. Das waren etwa 0,15 $ pro Stück. Der Entwicklungsleiter hatte noch nie Code-Profiling gemacht und bekam es auf 0,01 $ pro Stück herunter, aber selbst das war noch absurd.

  • Ich verstehe nicht, warum das Erzeugen eines einzelnen QR-Codes so viel kosten sollte, wenn sonst nichts Besonderes passiert. Selbst mit Edge-Cloud-Hosting müsste das kostenlos machbar sein.

• Ich verstehe nicht ganz, warum man sechs Staging-Server braucht (je 500 $). Falls das an einem großen Team liegt, sind 3.000 $ Serverkosten doch im Vergleich zu Personalkosten von über 100.000 $ im Jahr eher gering, oder? Ich habe mir idealist.org angesehen — das ist doch letztlich nur ein Job-Board, das wirkt ziemlich überzogen.

  • Die sechs Staging-Server dienen dazu, main, dev und mehrere Branches bereitzustellen, damit auch nichttechnische QA sie direkt prüfen kann. Mit jedem Staging-Deployment steigen die Kosten schnell: ein Performance-M-Dyno, mehrere Standard-Dynos, RabbitMQ, Datenbank und so weiter. Der Idealist-Dienst hat täglich 100.000 Nutzer, daher steckt hinter Zuverlässigkeit und Geschwindigkeit eine Menge Technik.

  • Beim Lesen hatte ich den Eindruck, dass mehrere Staging-Server nötig waren, weil sie als Entwicklungsumgebungen dienten, in denen pro Entwickler mehrere Dienste gleichzeitig laufen konnten.

  • Bei realen Kostenrechnungen übersehen viele die Personalkosten in Manntagen.

• Ich möchte Heroku ersetzen und eigentlich nur meine Django-Site samt Datenbank dumpen, aber ohne selbst Systemadministration zu machen. Was ist dafür die beste Option?

  • Render.com kommt dem am nächsten und ich bin wirklich sehr zufrieden damit. Der Workflow ist praktisch derselbe wie bei Heroku, es ist günstiger, und sowohl nächtliche Neustarts als auch die Unterstützung aktueller Python-Versionen passen für mich.

  • Es lohnt sich auch, Docker Swarm zu lernen. Deployment geht dann mit einem einzigen Container-Push und einem einzigen Befehl. Ich habe außerdem selbst rove.dev gebaut, ein kostenloses CLI-Tool, das sowohl für Deployments als auch für Service-Diffs gedacht ist. Alternativ sind auch VM-basierte PaaS-Lösungen empfehlenswert, etwa Semaphore, Dokku oder Dokploy.

  • Man wählt einfach den gewünschten VPS nach Preis/Leistung/Standort/Support aus und setzt dann ein Deployment-Tool wie Coolify oder Dokploy darauf. Ich habe kürzlich Django/Postgres relativ einfach mit Coolify und Mythic Beasts von Google App Engine migriert. Obwohl meine Kenntnisse ziemlich eingerostet waren, ließ sich die Migration wirklich problemlos durchführen.

  • Ich denke, es reicht völlig, einfach einen Server bei Hetzner hochzuziehen und dort nginx sowie ein paar systemctl-Services einzurichten.

  • PythonAnywhere (Link) ist auch okay.

• Cooles Projekt. In der Dokumentation sieht es so aus, als sei die GitHub-Integration bei Disco zwingend erforderlich — stimmt das? Und kann man auch einfach bestehende Docker-Images aus einer eigenen Registry direkt deployen, ohne separaten Build-Prozess, ähnlich wie bei Kamal mit --skip-push --version latest?

  • Ja, aktuell ist die GitHub-Integration erforderlich. Disco kann aber auch bereits existierende Docker-Images direkt abrufen und deployen (wir self-hosten RabbitMQ auf diese Weise). Beispiele dafür, wie man ein Meilisearch-Image deployt, finden sich hier und in diesem Tutorial. Mich würde interessieren, ob du üblicherweise baust und dann in eine Registry pushst, und ich würde gern mehr über deinen konkreten Deployment-Prozess hören.