A developer with a side project asked Hacker News a question every cohort re-asks: I've got a few Docker containers running under compose locally — two Python apps, a Postgres database, a cleanup cron, and soon a reverse proxy — and I want to publish it. Should I learn managed Kubernetes, or rent a vServer and build it with the help of ChatGPT and Claude? Oh, and what do people think of dokku and dokploy?
The thread (HN #44020505, May 2025) is small — one point, three comments — and that is exactly why it is useful. Nobody showed up with a whitepaper. The answers were a Kubernetes-manifest side project, a $1/app/month promo, and a hand-rolled dashboard. The fragmentation is the finding: for a four-container app, the industry has no default answer, only tribes. So here is the default answer, priced five ways, with the rule for when it changes.
The bill first: the same stack, five monthly totals
Reference workload, taken straight from the thread: two small Python web apps, one Postgres, one scheduled cleanup container, one reverse proxy (Caddy or Nginx), secrets in a single env file. Low traffic, one developer, almost no ops experience. Prices observed September 2026; re-check live pages before budgeting, because the deltas matter more than the cents.
| Option | What you pay for | Total / mo | Notes |
|---|---|---|---|
| Hetzner CX22 + Compose (or Dokploy) | CX22: 2 vCPU, 4 GB RAM, 40 GB disk, 20 TB transfer, €3.79 excl. VAT (~€4.51 incl.) | ~$5 | Whole stack on one box; TLS and deploys via Caddy + Dokploy/Coolify, all free |
| DigitalOcean droplet + Compose | Basic droplet 1 GB at $6 (512 MB at $4 is too small once Postgres warms up) | ~$6 | Same shape as above, friendlier docs, roughly 2x the price per GB of RAM |
| Railway Hobby | $5/mo plan including $5 of usage credit, then metered | ~$5–15 | Compose file becomes services; Postgres is one more metered service; the $5 trial credit covers the experiment |
| Render Starter | ~$7 per always-on service × 2 apps, ~$6–7 Basic Postgres, cron on top | ~$21–28 | Flat per-service pricing: honest, predictable, and the most expensive hosted answer here |
| Managed Kubernetes (DOKS), minimal | Control plane free, 2 × $12 worker nodes, $15 single-node managed Postgres | ~$39 | Single-node $12 cluster exists and is fine for staging; nobody should run the cleanup cron's database on it in production |
| Managed Kubernetes (DOKS), production-grade | Above plus the $40/mo HA control plane | ~$79 | This $40 line is the $40 in the title: the gap between "Kubernetes runs" and "Kubernetes is operated" |
Title shorthand, disambiguated: the $5 is the left edge of the table — a Hetzner-class box or a Railway Hobby plan, the price of the question's cheapest honest answers. The $40 is DigitalOcean's HA control-plane fee, the line item that separates hobby Kubernetes from the thing its advocates picture when they say "just use managed K8s." Everything below defends each row.
Door one: a vServer and an AI assistant
This is the 2026 twist in an old question, and it is a real improvement on 2016's version of it. An assistant will write you a perfectly good Caddyfile, a systemd unit for compose, a UFW ruleset, and a backup cron with pg_dump to object storage — in minutes, with explanations. For setup, "rent a box and ask Claude" genuinely compresses a weekend of tutorial-following into an evening.
What it cannot do is be on call. Enumerate what the thread's stack needs after launch day and notice how little of it is setup-shaped: TLS certificates renewing every 60–90 days, unattended OS security upgrades, Postgres minor-version patches, disk-filling-up alerts nobody configured, the 3am OOM when the cleanup script and a traffic bump coincide, and in a year or two, the OS end-of-life migration one HN commenter from an older thread named as the moment they wished they'd been on managed infrastructure all along. An AI assistant answers questions; operations is the discipline of noticing the questions nobody asked. That is the whole tax on door one: not the setup evening, but the background process of remembering the box exists, forever, for about $5 a month in hardware and an unbounded amount in attention.
The thread's own Dokku/Dokploy question points at the patch: a single-box panel automates the remembering for deploys, TLS, and restarts. Dokku (CLI-first, git-push, no Compose for multi-service) fits single apps; Dokploy and Coolify (web UI, Compose-native, free and open source) fit exactly this four-container shape. The box is still yours when the disk fills at 3am — but at least the TLS renewal isn't.
Door two: managed Kubernetes and its complexity tax
"Managed" in managed Kubernetes covers the control plane — etcd, the API server, the scheduler, upgrades of those components. It does not cover your manifests, your Postgres backups, your image registry, your log retention, your alerting, or your understanding of why a pod is CrashLooping. For a four-container app, that uncovered remainder is nearly the entire job, and Kubernetes makes each piece heavier: Deployments plus Services plus Ingress plus PersistentVolumeClaims plus SealedSecrets-or-external-secrets plus a backup Job, where compose needed one file and an env file.
Price it honestly and the tax is visible before the complexity is. The minimal DOKS row ($39) is already 8x the single box, and it still contains a single-node $15 Postgres — the managed-database half of "easy to scale" that the thread author sensibly wanted to buy separately. The production row ($79) adds the $40 HA control plane, which is the moment the comparison gets fair: a single non-HA control plane is staging with extra steps, and everyone recommending K8s in these threads is picturing the HA version without pricing it.
So when does the tax pay off? Past a threshold most small projects never reach: enough services (rule of thumb: past ~8–10, when compose files become YAML archaeology), enough environments (staging + prod + per-PR previews, where namespaces and GitOps beat directories of compose overrides), or enough operators (a team where "kubectl access with RBAC" beats "SSH into the box"). The thread's top instinct was right in substance if not in votes: Kubernetes' complexity tax is fixed, its benefits scale with service count, and four containers do not clear the bar. Note what this also rules out: the single-$12-node DOKS cluster, the most tempting row on the price page. One node is a vServer with a kubelet tax and none of Kubernetes' availability story — the worst of both doors.
Door three: the git-push middle that ate the thread
Look at where the market actually moved since this question was first asked a decade ago. The thread's answers — a Compose-native panel, a $1/app deploy service, a personal dashboard — are all attempts to sell door one's price with door two's ergonomics. The mature versions: Coolify (58K+ stars, 481K+ instances, Compose-native, multi-server) and Dokploy (lighter, Swarm-native, still pre-1.0) on your own $5 box; Railway and Render if you'd rather rent the whole answer per service. This middle is why the thread feels unresolved: the question assumes two doors, but most four-container apps in 2026 walk through a third one the asker hadn't priced — git push, automatic TLS, managed Postgres add-on, no manifest writing, no 3am disk pager that is yours alone (on hosted PaaS there is still a pager; it just isn't you).
The middle has exactly one honest limit, and the thread's stack will hit it the day the project grows up: the second machine. Single-box panels manage the box you have; they do not provision the next one, reconcile fleet state, or fail over across hosts. Coolify's multi-server support narrows this; hosted PaaS erases it by charging per service forever (that $21–28 Render row scales linearly with every service you add, which is the business model, not a bug). Name the limit upfront and the middle stops being a trap: it is the correct answer until the second machine, and the migration it postpones is a good problem — it means the side project survived.
The framework: experience × services × traffic
Three variables pick the door; score yours:
- Ops experience (low?) — Rent the answers you don't have. No experience plus no interest in acquiring it: hosted git-push PaaS. No experience but curious: single box plus a panel, with an AI assistant for setup. Experience: you already know which door you're in.
- Service count (≤ ~6?) — Stay out of Kubernetes. The thread's four containers, plus a proxy and maybe Redis later, live happily in one compose file for years. Past ~8–10 services, or the first time you need staging and prod and previews, re-open door two.
- Traffic shape (boring?) — Flat low traffic means the $5 box is 90% idle and that is fine; idle headroom on flat-rate hardware is free. Spiky or "might hit the front page" means you want either horizontal scaling you tested (door two) or someone else's pager (hosted PaaS) — not a single box you haven't load-tested.
Sensitivity, because one convenient point proves nothing: if traffic 10x's overnight, the ranking flips to hosted-PaaS-first (autoscaling you didn't have to build) and the $5 box last (it falls over at 3am and the assistant can't ssh in for you). If the project grows a cofounder and six more services, door two starts earning its tax. If nothing changes — the modal outcome for side projects — the cheapest answer stays correct indefinitely, and "boring" was the feature, not the compromise.
Close: boring is a feature until it isn't
The thread asked for a go-to stack, so here is one, stated plainly: a Hetzner-class box, Docker Compose, Caddy for TLS, Dokploy or Coolify the day manual deploys annoy you, managed Postgres (any vendor's $15 tier) the day your data matters more than your $5 streak, and Kubernetes the day your service count or team size makes the tax deductible. That ladder is the whole post in one paragraph; every section above is just the receipts.
The ladder's top rung — PaaS ergonomics on machines you own, with the second machine handled by declarative fleet management instead of a migration project — is what we're building with Bex.co: push a git repo, get a running HTTPS service on hardware you control. Star the repo on GitHub or deploy your first app today.



