Short answer: one "hello world" container with a domain and HTTPS costs about $32 per month on AWS if you set it up carefully, and about $69 per month if you follow the default AWS tutorial. The same thing on a small Hetzner Cloud server costs €5.99 per month. Bare metal is the surprising one. A Hetzner AX42-1 costs €97.30 per month, which makes it the most expensive option here, not the cheapest.

Two results are worth explaining, and neither is what people usually say:

1. Compute is not the expensive part on AWS at this size. In the realistic setup, the container is 15% of the bill. The other 85% is the load balancer and the NAT gateway. Those cost the same whether you serve one request per month or a million.
2. Bare metal is not cheap. It is cheap per app. A dedicated server only pays off when you fill it. For one container it is a bad deal.

Short answer first: at the same size (2 vCPU / 4 GB, PostgreSQL 16), Hostim had the fastest writes, about 2.5× the write throughput of AWS RDS db.t4g.medium and 2.1× a default self-hosted Postgres on Hetzner. Hetzner had the fastest reads, on raw per-core CPU speed. RDS was slowest or near-slowest on both, and its listed price is the smallest part of the real bill.

This post shows every number, the exact commands to reproduce them, and (because it changes the conclusion) what high availability actually costs on each platform.

Short answer first: the three platforms charge in three different shapes. Render adds a workspace fee for teams on top of fixed instance prices. Railway has no free tier and meters everything per second on top of a small plan fee. Fly.io is pure pay-as-you-go per second, with no base plan fee at all. The right pick depends less on the headline price and more on which of those shapes fits how you work.

This post explains each model, shows a side-by-side table, and gives the cases where each one wins.

Short answer first: use Supabase if you want Postgres plus auth, realtime, storage, and a dashboard as one managed bundle. Self-host Postgres – or use a managed Postgres – if you mostly need a database and your app already handles its own auth and logic. The choice is not really "Postgres vs Supabase". It's whether you need the extra layers Supabase puts on top of Postgres.

This post gives you a clear way to decide, a side-by-side table, and the cases where each option is the right one.

Usage-based pricing always looks cheap on the signup page. "Pay only for what you use." "Starts at $5." Then a few months in, your bill is double what you guessed, and you can't really point at the one thing that did it.

I've been comparing platforms a lot lately – partly because I run one, partly because people keep emailing me to ask whether X or Y is cheaper than Hostim. So here's the actual math on why metered hosting drifts upward over time, and the honest version of when it's the better deal anyway.

If you run Kubernetes and want a wildcard TLS cert from Let's Encrypt — say *.example.com — you need a DNS-01 challenge. HTTP-01 cannot prove control over a wildcard. That single fact rules out the easy path most tutorials show.

This post is what we actually run at Hostim.dev for our shared *.region.hostim.dev wildcard. We use cert-manager for per-app certs and a plain certbot Ansible playbook for the wildcard. Two different tools for two different jobs. We will explain why, then show the code for both.

Most small teams hit the same question at some point: should we move to Kubernetes? The honest answer for the majority of them is no, but that answer alone is not very helpful. So here is the longer version, with real prices and a clear line where the answer flips to yes.

When you're deploying your own app, the database choice matters more than most people think. It affects performance, ops complexity, backups, and how much memory your server needs.

There are four options you'll run into most often: SQLite, MySQL, PostgreSQL, and Redis. They're not all the same kind of database – and that's the point. Here's when each one makes sense.

Heroku just said it's moving to a "sustaining engineering" model.

That's corporate speak for:

• No big new features
• Focus on stability and security
• No new enterprise contracts
• Maintain what exists

Heroku isn't shutting down.

But it's not a growth product anymore.

I haven't posted updates for a while, but several core features landed on Hostim.dev recently.

Instead of shipping from a fixed roadmap, I'm following support-driven (customer-driven) development: features move to the top of the queue once users actively need them.

Over the past month, this resulted in three practical additions around Docker CI/CD, GitHub Actions deployment, and secure bastion host access.