
Sechzig Container auf einem Server
Eine Bare-Metal-Box führt Dutzende bis Hunderte von Hoody-Containern aus. KSM und BTRFS-Dedup machen die Marginalkosten nahezu null.
Elf halbfertige Side Projects auf Heroku sind elf Dynos zu 7 $/Monat. Auf Hoody sind es elf Container auf einer 29-$-Box. Idle Container kosten null. Die URL weckt den Container in Millisekunden, wenn jemand endlich die Schach-Engine besucht, die du 2023 geschrieben hast.
12 PROJEKTE · 1 BARE-METAL-BOX · IDLE = 0¢/STD
Ein Hoody Container ist eine echte Linux-Maschine, die nicht laufen muss, um günstig zu sein. Die meisten Projekte verbringen ihr Leben in der mittleren Spalte.
POST /containers/[id]/stop drückt CPU und RAM auf null. Nur das BTRFS-Delta auf der Disk überlebt — meist ein paar hundert Megabyte. Der Container ist weg, aber das Projekt ist es nicht.
Hier liegen die meisten deiner elf Projekte. Kein Prozess läuft. Kein RAM ist allokiert. Das Einzige, was die Box bezahlt, ist das Dateisystem, und BTRFS dedupliziert das Base-Image über jeden Container auf dem Server hinweg.
Ein GET an die Container-URL bootet ihn in 5–15 Sekunden (kalt) oder sofort (paused). Der Besucher sieht ein kurzes Laden, der Request landet, und der Container schläft wieder ein, wenn der Traffic abklingt.
Hoody dokumentiert drei Lifecycle-Operationen auf einem Container: stopped (keine CPU, kein RAM, Dateisystem bleibt erhalten), paused (im RAM eingefroren) und der active-Zustand. Stopped ist der natürliche Ruhezustand des Friedhofs — das Disk-Delta hält das Projekt zu nahezu null Grenzkosten am Leben.
Zwei Fenster. Der Besucher schickt ein normales GET. Der Container bootet, liefert aus und schläft wieder ein. Der ganze Flow läuft über dieselbe Hoody-URL, die das Projekt schon immer hatte.
POST /api/v1/containers/[id]/start ist die explizite Lifecycle-Operation; das Routing über den HTTPS-Hostname des Containers triggert dasselbe Wake automatisch. Es gibt keinen separaten Wake-Endpoint — die URL aufzurufen IST das Wake.
Wenn idle gratis ist, sind die elf Projekte keine monatliche Kostenfrage mehr, sondern ein Ordner. Die Entscheidungen, die du früher getroffen hast, sind keine Entscheidungen mehr.
Das Skript, das dich pingt, sobald die 1099-Formulare draußen sind, läuft einmal im Jahr. Auf einem 7-$/Monat-Dyno sind das 84 $ pro Feuer. Hier schläft es 364 Tage, wacht für einen einzigen HTTP-Call auf, schläft wieder ein. Du hast vergessen, dass du es geschrieben hast. Es funktioniert trotzdem.
Jemand hat deinen `recipe-tracker-2022`-Blogpost zwei Jahre zu spät auf Hacker News gefunden. Der Link löst noch auf. Der Container wacht auf, rendert die Seite und schläft wieder ein. Du hast keine 30-$-Rechnung für den Spike bekommen.
Bei einem Pricing pro App rationierst du Ideen, bevor du sie baust. Hier nicht. Push die halbfertige Sache. Vergiss sie. Find sie Jahre später wieder. Öffne die URL. Sie ist immer noch da.
Pro-App-Hosting rechnet dir die Sekunde ab, in der deine elf Projekte keinen Traffic bekommen. Pro-Server-Hosting rechnet einmal die Box ab und lässt die Projekte sich darin stapeln.
Elf Heroku-Eco-Dynos zu ~7 $ je, oder elf Render-Web-Services. Gleiche Rechnung, ob jemand vorbeischaut oder nicht.
Ein Hoody-Server ab dem Preis von zwei Dynos. Elf Container passen rein. Der zwölfte ist gratis.
BTRFS-Delta + KSM-Dedup heißt: ein gestoppter Container kostet nur Disk. Der Schlafzustand wird nicht abgerechnet; die Box wird abgerechnet.
Hoody-Marketplace-Preise variieren nach Region und Spec; der dokumentierte Einstieg liegt bei rund 20 $/Monat. Die Container-Dichte hängt vom Workload ab — leichte Side Projects packen dicht, alles, was RAM heiß hält, braucht mehr Spielraum.
Der Friedhof ist keine Hosting-Rechnung mehr. Er ist ein Ordner.
Pro-App-Hosting-Pläne rechnen dir jedes ruhende Projekt ab. Pro-Server-Pricing zieht dem Friedhof eine weiche Decke ein. Die Plattformen unten rechnen pro Side Project ab, nicht pro Server:
Du kannst sie alle behalten. Der Ordner ist die Grenze, nicht das Budget.