Flat pricing: the bill a bot can't run up

There is a hosting pricing model missing from the usage-vs-fixed debate, and for anything that runs all the time it is both the cheapest and the safest: flat pricing - a fixed server you own plus a flat platform fee, with no meter for a bot to run up.

Why it matters: On usage-based pricing, the app you watch least - a prototype, an internal tool - is one misconfigured AI crawler or one bot away from a four-figure bill or an outage. Flat pricing removes that failure. The worst a bot can do is slow a server whose price you already set.

The big picture: Railway's piece on usage-based vs fixed pricing is fair and right: no model is universally cheaper, so match the model to the workload. It sorts hosting into three:

• Provisioned capacity - a fixed VM on a platform, paid whether you use it or not. Predictable, but still the provider's hardware. Render's 0.5 CPU / 512 MB starts at $7/month.
• Pay-per-use - billed for what you consume. Wins on variable load. Railway's full-stack app runs $21.95/month against about $38 on Render.
• Pay-per-request - servers abstracted away, billed per invocation, scale-to-zero when idle. Fits frontend-first and spiky apps.

Each bundles three things into one invoice: raw compute, operations (build, deploy, HTTPS, logs, monitoring, backups), and the provider's margin. Flat pricing is the row the matrix skips.

How it works: Rent the raw compute from whoever is cheapest - Hetzner, Vultr, DigitalOcean, a GPU host - and pay a flat fee for the operations. That is DollarDeploy: a control plane that builds and deploys to servers you own, with SSL, logs, monitoring, and rollbacks handled. No Docker, no Terraform, no SSH. The bill has two fixed lines and no third.

By the numbers:

• ~$12.09/month all-in - a Hetzner CAX11 at ~$7.09 plus the $5 control plane - against ~$20 on Vercel and ~$33 on AWS for the same class of app.
• 10-30% of a hyperscaler across real workloads.
• No metered tail. Railway charges $0.05/GB egress; Vercel overage is $0.15/GB, or $150 per terabyte. A Hetzner box includes 20 TB, then bills in dollars per terabyte. The number is one you chose, not one you discover.

The tail nobody watches: Usage-based pricing hurts most where you watch least. On pay-per-request you pick the failure - no cap, and a runaway crawler is a four-figure bill; a spend cap, and the app is offline when a real user arrives. Flat pricing has no such tail: the box saturates, slows, you throttle it or size up, and the month-end invoice is the number you picked. We took apart the other outcome in Decomposing a $46K Vercel bill, and it is sharpest with a GPU: an endpoint costs the same for ten tokens or ten million, as we showed on a single H200.

Yes, but: for a genuinely idle app you can babysit, scale-to-zero is cheaper in absolute dollars - until something hammers it. Match the model to the workload:

• Idle or spiky, cold-start tolerant -> pay-per-request / scale-to-zero.
• Variable utilization, always-on but light -> pay-per-use.
• Small, predictable, well-sized -> provisioned capacity.
• Always-on, in production, a fixed budget, data that cannot leave your servers, or a GPU -> flat pricing.

The bottom line: Railway is right - match the pricing model to the workload's shape. Flat pricing is the row to add, and the one that also protects the app you forgot about. For anything you run continuously, or would rather not babysit, it is the cheapest and most predictable option.

Go deeper:

• Decomposing a $46K Vercel bill
• Your own inference with vLLM, on a single H200
• Why self-host Next.js apps

Deploy to your own VPS from $5/mo. Next.js, Go, Python with automatic HTTPS. No Vercel bills, no Docker, no lock-in. Start free or email hello@dollardeploy.com.