Aus der Garage: Warum wir keinen Server mehr mieten

Wir mieten keine Server mehr. Keinen einzigen. Kein VPS, keine VM, nichts, wofür wir nachts per SSH ran müssen. Das ist keine Ideologie, das ist eine Rechnung, die wir irgendwann ehrlich aufgemacht haben.

Aufgebockt

Wir bei Agentic Punks sind ein kleines Team. Wir bauen laufend Dinge, die live gehen müssen: ein Chat-Backend für unsere Website, die Website selbst, den Podcast mit Feed und Audiodateien, eine Kundenseite, eine Pipeline, die Daten anonymisiert. Alles Sachen, die früher selbstverständlich auf einem gemieteten Linux-Server gelandet wären. Ein VPS, Docker Compose drauf, Caddy als Reverse-Proxy davor, GitHub Actions deployt per SSH. Kennt jeder. Läuft. Bis es nicht mehr läuft.

Wir machen das inzwischen anders. Jeder dieser Workloads liegt bei unserem Hosting-Provider Scaleway als Serverless-Dienst oder als Managed Service. Das Chat-Backend ist ein Serverless Container mit einer managed Postgres-Instanz (RDB) dahinter. Website und Podcast-Audios liegen in Object Storage hinter Edge Services. Mails gehen über TEM (transactional emails). Wir besitzen keine Server und müssen keine Betriebssysteme patchen.

Wo’s klemmt

Der Reflex sitzt tief: Neues Projekt, also miete ich einen Server. Das fühlt sich unschlagbar günstig an: fünf Euro im Monat für einen kleinen VPS, was soll da schon dran sein.

Der wahre Preis eines gemieteten Servers steht nicht auf der Rechnung. Er kommt später. Das Sicherheitsupdate, das man verschlafen hat beispielsweise, oder der volle Log-Ordner, der die Festplatte dichtmacht. Gerne auch das Zertifikat, das um drei Uhr morgens ausläuft oder die eine Zeile in der Caddy-Config, die nach dem Reboot fehlt. Das ist die Arbeit, die niemand einplant und die trotzdem jeden Monat kommt. Bei einem Team unserer Größe ist genau diese Arbeit das Teuerste, was wir haben. Sie lässt sich kaum delegieren, weil sie immer dann anfällt, wenn gerade niemand Zeit dafür hat, und weil sie Kontext über das eine gewachsene System verlangt, das nur einer im Kopf hat.

Der Dreh

Der Moment, in dem es klick machte, war unspektakulär. Wir haben eine Kundenseite neu deployed, ein simpler container update --redeploy. Das tauscht nur das Container-Image aus. Die managed Postgres-Instanz daneben wird dabei nicht angefasst, sie hat mit dem Deploy gar nichts zu tun. Der Container ist zustandslos, alle Daten liegen woanders.

Das ist der ganze Trick. Sobald der “state” aus dem Container raus ist, in eine managed Datenbank, in Object Storage, in einen Secret-Store, wird der Container selbst wegwerfbar. Es gibt kein “der Server”, den man gesund halten muss. Es gibt ein Image und einen Haufen managed Bausteine, die Scaleway wartet, nicht wir.

Dasselbe Muster zieht sich durch alles. Diese Website hier deployt per hugo deploy direkt in einen Object-Storage-Bucket, davor Edge Services für Cache und TLS. Kein Webserver, den wir konfigurieren. Auch die Podcast-MP3s liegen in einem eigenen Bucket, der Feed wird statisch gebaut. An keiner Stelle steht eine Maschine, die läuft und gewartet werden will.

Was hält

Ja natürlich, eine managed Postgres kostet mehr als Postgres im Container auf dem Fünf-Euro-VPS. Auf dem Papier. Wir zahlen den Aufpreis trotzdem gerne, bewusst, auch bei lächerlich kleiner Last. Zwei Nutzer:innen am Tag rechtfertigen managed Postgres, weil die eingesparte Ops-Zeit mehr wert ist als die Differenz auf der Rechnung. Das ist unsere Faustregel: Rechne die Wartungszeit, nicht den Hosting-Preis.

Konkret, wenn ihr das nächste Mal einen Workload unterbringen müsst, greift in dieser Reihenfolge:

• Zustandsloser Code, der auf Requests reagiert? Serverless Container.
• Ein Job, der ab und zu läuft (Backfill, Cron, Verarbeitung)? Serverless Job.
• Daten, die bleiben müssen? Managed Postgres (RDB), kein DB-Container.
• Dateien, Bilder, Audio? Object Storage plus Edge, kein Volume auf einer VM.
• Mail? TEM, kein eigener SMTP.

Das Prinzip dahinter ist immer dasselbe: Zustand nach außen, Rechenkraft wegwerfbar.

Wer jetzt “Lock-in” ruft: geschenkt. Ein zustandsloser Container und eine Postgres-Datenbank sind so portabel, wie Software nur sein kann. Wir haben eine theoretische Abhängigkeit gegen sehr reale Nächte ohne SSH-Login getauscht. Diesen Tausch machen wir jederzeit wieder. Der einzige Server, den wir noch anfassen, ist der, den jemand anders wartet.