Drev hela företaget på en enda värd med 512 MB och en kärna — en git‑forge, en webbserver för sju domäner, Tor, två servrar för alternativa protokoll, säkerhetskopiering och intrångsblockering — genom att behandla 464 MB användbart minne som den bindande arkitektoniska begränsningen.

Situation. Företagets produktionsserver är en molninstans med en kärna, 512 MB minne och 10 GB disk, och av minnet går ungefär 464 MB att använda. Allt som verksamheten driver publikt ligger på den: webbservern som terminerar TLS för sju domäner, git‑forgen, en onion‑tjänst för Tor, en Gemini‑server, en Gopher‑server, krypterade säkerhetskopior och spärrning av intrångsförsök. Den vanliga reaktionen på en sådan lista är att köpa en större maskin.

Uppgift. Begränsningen måste behandlas som en förutsättning för arkitekturen snarare än som ett problem att lägga pengar på, eftersom den ärliga frågan inte var om en större maskin skulle fungera utan om designen behövde en.

Handling. Minnet blev det argument som avgjorde besluten. Det finns ingen övervakningsagent, ingen pipeline för mätvärden och ingen dashboard — rapporteringen är pull‑baserad: sju kommandon som läser servern och renderar Markdown, som inte ändrar någonting och bara körs när någon ber om det. Processerna övervakas av systemd i stället för av en andra processhanterare ovanpå den, och containerlagret består av Quadlet‑enheter under samma systemd i stället för en daemon med en egen processhanterare. Plattformar med webbpanel valdes bort redan i designskedet av samma skäl. När frågan kom upp om servern klarade att bära en onion‑tjänst kom svaret från ett dygns mätningar snarare än från en åsikt: tillgängligt minne föll aldrig under ungefär 310 MB av 464, swap låg på 2,6 % och processorn var i vila 99,7 % av tiden.

Resultat. Hela företaget körs på en maskin som kostar mindre per månad än en lunch, och designen är bättre tack vare disciplinen, inte bara billigare. Priset är att det saknas marginal för slarv — e‑post ligger medvetet inte alls på den här maskinen — e‑postdelen är skriven som ett installationsskelett som väntar på en egen server, eftersom en e‑postserver behöver marginal som den här maskinen redan har förbrukat, och det står nedskrivet i stället för att upptäckas senare.