Why every micci project deploys to hoststack
hoststack is the European PaaS I built when Render's DX and Hetzner's prices wouldn't fit on the same invoice. A year in, here's why every project I ship lives there.
The first version of micci.dk lived on a single Hetzner box I'd been quietly maintaining for six years. It served three side projects, a staging environment, a Forgejo instance, and the kind of cron jobs you write at midnight and never document. It worked. It also meant that every time I wanted to ship something new, I'd spend an evening hand-rolling Caddy configs and remembering which UFW rule I'd added in 2022 to keep a port closed.
The bill was forty-something euros a month. That part was fine. The rest of it wasn't.
A new project always started the same way. SSH in. apt update. Wonder briefly if I should learn Ansible properly this time. Decide against it. Add another systemd unit. Add another reverse-proxy block. Hope the next deploy doesn't take the previous service down. Ship.
The alternative — moving to Render or Railway — kept failing the same arithmetic. The developer experience I wanted was sitting right there on render.com. So was the bill, in dollars, payable to a US company, with my data living in us-east-1 and a privacy policy that referenced the CLOUD Act in the small print. I'd run a Danish company on a Danish server for six years specifically to not have that conversation.
So I built hoststack. It's the platform-as-a-service I wanted, deploying to European Hetzner infrastructure, billed in euros, with the same git-push-and-it-deploys experience that everyone else has had for a decade.
This is the post about why every other project I ship now lives on it.
What hoststack actually does
The shape is unsurprising — and that's the point. If you've used Render, you already know what hoststack does. Git push, Docker build, zero-downtime blue/green rollout, custom domain, TLS via Let's Encrypt and Traefik, managed Postgres and Redis next to your service, log streaming, metrics, autoscaling, PR preview environments. WebSocket-streamed logs because nobody enjoys polling a log endpoint in 2026.
The unsurprising-ness is load-bearing. I do not want a PaaS that asks me to learn it. I want a PaaS that gets out of the way so I can think about the thing I'm actually building.
What is mildly surprising — and what I underestimated when I started — is how much falls out for free once the substrate is good. Managed databases that you can spin up next to a service in two clicks change how I scope projects. The first version of any new idea now includes Postgres because Postgres is no longer a thing I have to decide to operate. Same with Redis, same with NATS, same with Meilisearch. The platform's job is to make the building blocks cheap to reach for.
Eating my own cooking
There are three things in active production on hoststack right now, all of them mine.
The first is poststack, my email API, which has been live the longest. It handles inbound, outbound, SMTP relay, broadcasts, and workflows for a small but growing list of teams. It's the kind of workload that breaks if the platform under it has a bad week. So far, it hasn't.
The second is this site — micci.dk — running as an apps/api + apps/web pair behind a managed Postgres + Redis. It auto-deploys on every push to main. The blog post you're reading is being served by a container that didn't exist forty seconds before I clicked "Publish".
The third is skyskraber.dk, my hobby chat universe. That one is much heavier — 51 WebSocket modules, real-time room state, a Stripe-integrated economy. It is, in operational terms, the most demanding of the three. It also auto-deploys on push, and the WebSocket handover between blue and green during a rollout is invisible to connected users.
Dogfooding is not a marketing line for me. It's a feature-gating mechanism. If a paper cut hits me running my own services, it gets fixed before it ships to anyone else. The micci.dk launch turned up a real one: a managed Postgres container went into a restart loop and quietly stopped getting reattached to the project network. The api couldn't reach the database. The control plane reported the database as "running". I spent a tense afternoon writing a recovery script. That script (fix-db-networking.ts) now lives in this repo, but the underlying agent dispatch was tightened in hoststack itself so the next person doesn't have to write the same script.
That feedback loop — me as the angry customer, me as the on-call engineer, me as the platform owner — is the one I'd point at if you asked why I think this approach works.
The MCP loop, which I keep forgetting to talk about
hoststack ships a Model Context Protocol server alongside the CLI and the TypeScript SDK. That means I can deploy and debug from inside Claude Code — the AI pair-programmer is a first-class consumer of the platform's control plane.
In practice this means I can type "what's wrong with micci-api?" and the assistant will walk through get_deploy_logs, list_env_vars, get_service_metrics, and diagnose_deploy without me ever touching the dashboard. It will then propose a fix, and — if I let it — apply it. Half the deploy fixes in the micci.dk launch happened that way.
The reason I keep forgetting to mention it is that it doesn't feel like a feature. It feels like the normal way to operate infrastructure now. But every other PaaS I've used has either no MCP integration or an aftermarket community wrapper. Building it in alongside the SDK from day one is one of the bets I'm proudest of.
Where hoststack falls short
I'd rather you find these out from me than from a Hacker News thread.
No global edge. hoststack runs in Hetzner regions inside the EU. If you serve users in Singapore from a single origin, you'll feel that. Most B2B European traffic does not care. Most consumer European traffic doesn't either. If you specifically need anycast and POPs in twenty cities, this isn't the right platform — yet.
You're betting on a small team. The flip side is that you can email me, or anyone else who works on this, and a person who can actually fix your problem will read it. There is no Tier 1 support that tells you to clear your browser cache.
No managed Kubernetes. If you want a knobs-and-dials orchestration layer, this is the wrong product. The whole point is that the orchestration layer is invisible. We've drawn the line very deliberately: hoststack is for teams who'd rather think about their product than their cluster.
The MongoDB managed offering is younger than the Postgres one. The Postgres path has been hardened across a year of dogfooding and customer use. Mongo got added more recently. If you'd be the canary, I'd rather you knew that.
Where to read more
If you want the deeper case for European infrastructure, the hoststack blog goes into all the places I'm hand-waving here:
The best European alternatives to Render, Railway, and Heroku in 2026 is the comparison piece. Includes hoststack, includes the obvious bias.
GDPR-compliant cloud hosting in 2026 is the compliance-focused walkthrough — data residency, sub-processors, the bits your DPO will ask about.
EU digital sovereignty: a practical playbook for leaving US cloud providers is the migration story for teams who already know they're moving and are looking for the order of operations.
If you're already on Render or Railway and the egress invoice is the thing keeping you up at night, the European startup credits program is the lowest-friction way to try it on a real project.
And if you're a fellow solo founder, the part of this you should steal isn't the platform choice — it's the dogfooding loop. Run your own products on your own platform. Be your own angriest customer. Everything you fix benefits everyone else who shows up next.
Was this useful?