Run the whole app on Hetzner. Monk brings the managed part.

Cheap compute, then Postgres

The “we moved to Hetzner” write-ups all report a much smaller bill, followed by a paragraph about who owns the database now. One developer priced Hetzner against managed Postgres at every size, found Hetzner cheaper every time, and bought managed anyway. The reason given was that managed means the provider owns the 3am page.

Each of the usual answers costs something. Kubernetes with a database operator is a platform you have to run before you run your app, and on Hetzner the control plane is yours. A single-box PaaS is fine for one app on one machine and stops there. Docker over SSH is where the 3am page comes from.

What Monk needs from a cloud

Monk’s orchestrator asks a provider for three things: machines to run containers on, a way for those machines to reach each other, and disks that survive a restart. Everything a managed cloud sells as a service above that line, Monk brings itself.

That is why Hetzner fits. On AWS, Monk will use RDS if you want it. On Hetzner there is no RDS, so Monk runs Postgres from its own package with a primary and a standby on two nodes, and treats it like any other workload it operates. The application gets a connection string either way.

What you had, and what runs here

This is not RDS, and calling it RDS would be a lie. It is a database that someone competent runs for you, on your machines, with the operations written down once instead of typed over SSH.

Around all of it Monk adds what none of those services give you on their own: stateless workloads relocated when a node dies, recovery policies with backoff, alerting, secrets kept out of the model’s context, and an approval gate on anything that spends money or destroys data.

Upgrading machines without downtime

Applications outlive their VMs. When Hetzner deprecates a server type or an operating system needs replacing, Monk does not patch machines in place. It grows the cluster with replacement servers, joins them to the same overlay, migrates the workloads while the old nodes are still up, and decommissions the old machines afterwards. The application stays reachable throughout.

Nobody has to run those steps by hand. You tell your coding agent what should change, which constraints apply, what it may cost and which actions need your approval; the agent and Monk carry out the operation. It is the same mechanism as a move between clouds, pointed back at the same cloud.

What it costs

Most of the gap is compute pricing and the 20 TB of egress Hetzner includes per server. The managed-service premium is only 10 to 12% at this size, so the saving is mostly in what the machines cost, not in what the services cost.

Hetzner repriced twice in 2026, and its shared CX plans were sold out in all three EU locations when we last checked, so price what is orderable on the day. On the plans you can order, this stack still lands between a third and a half of the AWS bill.

Moving in, moving out, or half of each

The app description does not name a cloud. One cluster can hold a Hetzner node and an AWS node at the same time, because the overlay runs over public IPs and does not depend on either provider’s private network. A move is the same operation as a resize: add nodes in the new place, migrate the workloads, remove the old nodes.

Partial moves work the same way. Keep Postgres on a managed provider and put only the compute on Hetzner. Or run everything on Hetzner and keep a CDN in front. If Hetzner stops being the right place, the same description goes back the other way.

What to know before you move

Hetzner volumes are network disks, capped at 5,000 IOPS and 200 MB/s whatever their size, with latency spikes under load. Fine for most applications, wrong for a write-heavy database, which belongs on local NVMe with a standby on another node.

There are no availability zones, the SLA is 99.9% per server with credits only, and there are no provider-side volume backups, so database backups are application-level and should leave Hetzner. Hetzner has suspended accounts at short notice: the account stays yours, Monk never holds it, and the exit is the same operation as the move.

Hetzner Cloud sells no GPUs. For GPU work Monk uses RunPod and the hyperscalers.