Flat rate cloud hosting means you pay one fixed monthly price for a known amount of compute - RAM, vCPU, storage - and run as many apps, databases, and workers as you want inside it. No per-app fees, no per-seat pricing, no usage meters. Your bill in a busy month is the same as your bill in a quiet month, and you know the number before the month starts.
That is the whole definition. The rest of this post is about why the model exists, when it wins, when it loses, and what to check before you trust anyone's "flat rate" label - including ours. Disclosure up front: Miget, our product, is a flat rate platform, so we have an obvious horse in this race. The comparisons below are still honest, because the model genuinely does not fit everyone.
The four ways clouds charge you
Every developer-facing hosting bill is built on one of four models, and most billing surprises come from not knowing which one you signed up for:
| Model | You pay for | Bill predictability | Typical examples |
|---|---|---|---|
| Per-service | Each app, database, and worker as a line item | Medium - grows a line at a time | Heroku dynos + addons, Render services |
| Usage-based (metered) | Requests, GB-seconds, CPU-hours, bandwidth | Low - scales with traffic and bugs | Railway, Vercel functions, AWS Lambda |
| Per-seat | Team members, multiplied by a base price | Medium - grows with headcount, not load | Vercel Pro, Netlify Pro |
| Flat rate | A fixed block of compute capacity | Total - the price is the plan | Miget, a VPS you manage yourself |
Notice the last row's second example: a plain VPS is the original flat rate cloud hosting. Hetzner charges the same whether your box idles or runs hot. What a flat rate platform adds is the part the VPS leaves to you - deploys, TLS, databases, previews, isolation - without switching the pricing model underneath.
Why the model exists: the marginal cost problem
On metered and per-service platforms, every new thing you run has a marginal cost. A staging environment doubles line items. A cron worker is another service. A second side project is another bill. So teams start rationing: previews get skipped, background jobs get crammed into web processes, the third microservice waits.
Flat rate inverts the incentive. Once the capacity is paid for, the marginal cost of one more app inside it is zero - the constraint is capacity, not the invoice. That changes behavior in ways that are easy to underestimate: you deploy previews without thinking, you split the worker out properly, you run the internal dashboard nobody would have paid a line item for.
The trade, stated plainly: you pay for capacity whether you use it or not. A flat plan sized for your peak is "wasted" at 3 a.m. That waste is what you exchange for never getting a surprise invoice - the same trade unlimited phone plans made against per-minute billing, and for the same reason: predictability is worth more than optimality to most people paying the bill.
When flat rate wins
- Always-on workloads. Web apps, APIs, SSR frontends, queues - anything that must stay warm. Per-second billing is at its worst exactly where always-on is at its most natural.
- Many small things. Agencies, side-project collectors, microservice stacks: ten apps on one plan versus ten sets of line items is where the models diverge fastest.
- Databases in the stack. On metered platforms the database is usually a separate SaaS with its own meter (the free tiers expire or pause). A flat plan that includes managed PostgreSQL, MySQL, Valkey, RabbitMQ, and Kafka at $0 removes entire bills, not just line items.
- Anyone who has been burned. If a bug, a bot, or a viral day has ever 10x-ed your invoice, you already understand the value of a bill that cannot move.
When flat rate loses
Honesty section. The model is a poor fit when:
- Your workload is genuinely spiky and short. A batch job that needs 64 GB for one hour a week is what usage-based pricing was invented for. Renting that capacity all month to use it 0.6% of the time is the wrong trade.
- Your site is static. A blog or docs site needs no standing compute at all - do not pay for always-on capacity to serve files that never change. Static hosting is its own product category with its own (often free) economics.
- You need instant elastic scale. Flat rate means a known capacity ceiling. Scaling is deliberate - you resize the plan - not automatic-and-billed-later. If Black Friday means 50x traffic for six hours, you want a meter (and its invoice).
Worth noting where this is heading: the models are not mutually exclusive, and the elastic-scale weakness is fixable without giving up the bounded bill. We are building flexible billing at Miget for exactly this - your flat plan stays the predictable floor for standing services, with optional pay-as-you-go capacity above it when you deliberately choose to burst past the plan. Bounded by default, elastic by choice. It is in the works, not shipped - this paragraph will link to it the day it is.
What to check behind a "flat rate" label
Marketing has noticed that developers want fixed prices, so the label gets stretched. Four questions expose the difference:
- Is the capacity real? Fixed price for guaranteed RAM/vCPU is flat rate. Fixed price for "up to" resources with throttling fine print is a metered plan wearing the label.
- Is anything still metered underneath? Bandwidth overages, per-request function pricing, or build-minute meters under a flat headline price mean the bill can still move.
- Are seats separate? A $20 platform fee plus $20 per teammate is per-seat pricing. Flat rate should price the compute, not the humans.
- Are databases included or adjacent? If Postgres is a separate metered product, your stack's bill is not flat - only the frontend's is.
Miget's answers, for the record: guaranteed capacity per plan (from $5/month for 512 MiB / 1 vCPU, plans here), no usage meters, five team seats included on every plan, and managed databases included at $0. Preview environments and unlimited apps are part of the same plan. If those answers stop being true, this post is the first thing that becomes false.
Frequently asked questions
Is flat rate cloud hosting cheaper than usage-based?
For always-on workloads, usually yes - a warm SSR app or API on per-second billing costs more than the same app on right-sized fixed capacity. For genuinely spiky workloads, no - you would pay for idle capacity. The honest answer is that flat rate is not "cheaper", it is bounded: you trade the best-case bill for a guaranteed worst-case bill.
What is the difference between flat rate and fixed price hosting?
In practice none - "fixed price cloud hosting" and "flat rate cloud hosting" describe the same model: a known monthly price for known capacity. "Flat rate" emphasizes that the bill does not move with usage; "fixed price" emphasizes that you know it in advance.
Does flat rate mean unlimited?
No, and be suspicious of anyone implying it does. Flat rate means a fixed price for fixed capacity - you can run unlimited apps inside that capacity, but the capacity itself is the honest ceiling. "Unlimited" with a fair-use asterisk is a meter you have not read yet.
Can I run databases on a flat rate plan?
On Miget, yes - PostgreSQL, MySQL, Valkey (Redis-compatible), RabbitMQ, and Kafka are included in the plan at no extra cost, with HA clusters when you outgrow a single instance. On most other platforms the database is a separate metered product, which is exactly what breaks the flatness of the total bill.
Who is flat rate cloud hosting for?
Developers and small teams running always-on full-stack apps who value a predictable bill over squeezing the theoretical minimum out of a meter: agencies hosting many client apps, indie hackers with several projects, and teams that have outgrown a free tier but do not want a usage invoice they cannot forecast.
If you want to see the model priced against the alternatives on real scenarios, the comparison series walks platform by platform: Heroku, Render, Vercel, and free PostgreSQL options.