Hvorfor alle micci-projekter deployer til hoststack

Den første version af micci.dk levede på en enkel Hetzner box jeg stille havde vedligeholdt i seks år. Den serverede tre sideprojekter, et staging environment, en Forgejo instans, og den slags cron jobs du skriver ved midnat og aldrig documenterer. Det virkede. Det betød også at hver gang jeg ville skibiere noget nyt, ville jeg bruge en aften på at hand-rolle Caddy configs og huske hvilken UFW rule jeg havde tilføjet i 2022 for at holde en port lukket.

Regningen var omkring fyrre euro en måned. Den del var fin. Resten af det var det ikke.

Et nyt projekt startede altid på samme måde. SSH ind. apt update. Undrer mig kort på om jeg skulle lære Ansible ordentligt denne gang. Bestemmer mig imod det. Tilføj en anden systemd unit. Tilføj en anden reverse-proxy block. Håb at det næste deploy ikke tager den tidligere service ned. Skib.

Alternativet - at flytte til Render eller Railway - blev ved med at fejle samme aritmetik. Den developer experience jeg ville have sad lige der på render.com. Det var også regningen, i dollars, betales til et US firma, med mine data levende i us-east-1 og en privacy policy der refererede til CLOUD Act i småtrykket. Jeg havde kørt et dansk firma på en dansk server i seks år specifikt for ikke at have den samtale.

Så jeg byggede hoststack. Det er platform-as-a-service jeg ville have, deployer til European Hetzner infrastruktur, faktureret i euro, med samme git-push-and-it-deploys experience som alle andre har haft i et årti.

Dette er indlægget om hvorfor alle andre projekter jeg skiberer nu bor der.

Hvad hoststack faktisk gør#

Formen er usurprenderet - og det er pointen. Hvis du har brugt Render, ved du allerede hvad hoststack gør. Git push, Docker build, zero-downtime blue/green rollout, custom domain, TLS via Let's Encrypt og Traefik, managed Postgres og Redis ved siden af din service, log streaming, metrics, autoscaling, PR preview environments. WebSocket-streamed logs fordi ingen nyder at polle en log endpoint i 2026.

Den usurprenderet-hed er load-bearing. Jeg vil ikke have en PaaS der spørger mig om jeg skal lære det. Jeg vil have en PaaS der kommer ud af vejen så jeg kan tænke på den ting jeg faktisk bygger.

Hvad der er mildt overraskende - og hvad jeg undervurderede da jeg startede - er hvor meget der falder ud for frit når substratet er godt. Managed databases du kan spinne op ved siden af en service i to klik ændrer hvordan jeg scoper projekter. Den første version af enhver ny ide indeholder nu Postgres fordi Postgres ikke længere er en ting jeg skal beslutte at drive. Samme med Redis, samme med NATS, samme med Meilisearch. Platformens job er at gøre byggestene billige at nå til.

Spiser mig selv mad#

Der er tre ting i aktiv produktion på hoststack lige nu, alle sammen mine.

Den første er poststack, min email-API, som har været live længst. Den håndterer inbound, outbound, SMTP relay, broadcasts, og workflows til en lille men voksende liste af teams. Det er den slags workload der bryder hvis platformen under det har en dårlig uge. Indtil videre har det ikke.

Den anden er dette site - micci.dk - kørende som en apps/api + apps/web par bag en managed Postgres + Redis. Det auto-deployer på hver push til main. Blog indlægget du læser bliver serveret af en container der ikke eksisterede fyrre sekunder før jeg klikkede "Publish".

Den tredje er skyskraber.dk, min hobby chat univers. Den er meget tungere - 51 WebSocket modules, real-time room state, en Stripe-integreret økonomi. Det er, operationelt set, det mest krævende af de tre. Det auto-deployer også på push, og WebSocket handover mellem blue og green under en rollout er usynlig for forbundne brugere.

Dogfooding er ikke en marketing linje for mig. Det er en feature-gating mekanisme. Hvis et papir cut rammer mig når jeg kører mine egne services, bliver det fikset før det skiberes til nogen anden. micci.dk lancering viste en rigtig: en managed Postgres container gik ind i en restart loop og stille holdt op med at blive vedhæftet til projekt netværket. Api kunne ikke nå databasen. Control plane rapporterede databasen som "running". Jeg brugte en anspændt eftermiddag på at skrive et recovery script. Det script (fix-db-networking.ts) bor nu i dette repo, men det underliggende agent dispatch blev strammmet i hoststack selv så den næste person ikke skal skrive det samme script.

Den feedback loop - mig som den vred kunde, mig som den on-call engineer, mig som platform ejeren - er den jeg ville pege på hvis du spurgte hvorfor jeg tror denne tilgang virker.

MCP loopet, som jeg holder på at glemme at tale om#

hoststack skiberer en Model Context Protocol server sammen med CLI og TypeScript SDK. Det betyder jeg kan deploy og debug inde fra Claude Code - AI pair-programmeren er en first-class forbruger af platformens control plane.

I praksis betyder det jeg kan type "hvad er der galt med micci-api?" og assistenten vil gå gennem get_deploy_logs, list_env_vars, get_service_metrics, og diagnose_deploy uden jeg nogensinde rører dashboard. Det vil så foreslå en fix, og - hvis jeg lader det - anvende det. Halvdelen af deploy fixes i micci.dk lancering skete på den måde.

Grunden til at jeg holder på at glemme at nævne det er at det ikke føles som en feature. Det føles som den normal måde at drive infrastruktur nu. Men alle andre PaaS jeg har brugt har enten ingen MCP integration eller en aftermarket community wrapper. Bygge det ind sammen med SDK fra dag et er en af de bets jeg er mest stolt af.

Hvor hoststack falder kort#

Jeg ville hellere have du finder disse ud fra mig end fra en Hacker News tråd.

Ingen global edge. hoststack kører i Hetzner regions inden for EU. Hvis du serverer brugere i Singapore fra en enkelt origin, vil du mærke det. De fleste B2B European traffic giver ikke. De fleste consumer European traffic heller ikke. Hvis du specifikt behøver anycast og POPs i tyve byer, er det ikke den rigtige platform - endnu.

Du satser på et lille team. Den anden side er at du kan maile mig, eller nogen anden som arbejder på det, og en person der faktisk kan fikse dit problem vil læse det. Der er ingen Tier 1 support der fortæller dig at ryd din browser cache.

Ingen managed Kubernetes. Hvis du vil have en knobs-and-dials orchestration layer, er det det forkerte produkt. Hele pointen er at orchestration layer er usynlig. Vi har trukket linjen meget bevidst: hoststack er til teams der hellere tænker på deres produkt end deres cluster.

MongoDB managed offering er yngre end Postgres en. Postgres stien er blevet hærdet over et år dogfooding og customer brug. Mongo blev tilføjet mere for nylig. Hvis du ville være canaryen, ville jeg hellere have du vidste det.

Hvor der skal læses mere#

Hvis du vil have den dybere case for European infrastruktur, hoststack blog går ind i alle stederne jeg hånd-waver her:

• De bedste European alternativer til Render, Railway, og Heroku i 2026 er sammenligningen stykket. Inkluderer hoststack, inkluderer det åbenlyse bias.

• GDPR-compliant cloud hosting i 2026 er compliance-fokuseret gennemgang - data residency, sub-processors, bitene din DPO vil spørge om.

• EU digital suverænitet: en praktisk playbook for at forlade US cloud udbydere er migration historien til teams der allerede ved de flytter og søger order of operations.

Hvis du allerede er på Render eller Railway og egress fakturaen er den ting der holder dig vågen om natten, den European startup credits program er den laveste-friktions måde at prøve det på et rigtig projekt.

Og hvis du er en anden solo founder, delen af det du skal stjæle er ikke platform valget - det er dogfooding loopet. Kør dine egne produkter på din egen platform. Vær din egen vredeste kunde. Alting du fikser gavner alle andre som dukker op næste.