Per-seat cloud pricing gets expensive: the flat-price alternative
Why per-seat and usage-based hosting bills climb with your team and traffic, and how one flat monthly price per server works instead. Draft from £8.
A hosting bill rarely arrives as one big shock. It creeps. A second developer joins, a staging environment appears, a database gets its own line on the invoice, and traffic grows a little. Each step is reasonable. The total, a year on, is not what you planned.
This post looks at why modern cloud pricing behaves like that, how the common pricing models differ, and what a flat price per server looks like in practice. We build Aria, which uses the flat model, so keep that in mind as you read. We will say where the other models are the better fit.
The four ways cloud platforms charge
Most platforms mix these four.
Per seat. You pay for each person who can deploy or manage. Vercel’s Pro plan, for example, includes a limited number of paid seats and charges for more; the rates are on its pricing page, and viewer-only seats are described there separately.
Per instance or dyno. You pay for each running unit of your app. Heroku’s published pricing is built around dynos, with different sizes at different prices, and databases billed as add-ons. See Heroku’s pricing for the current figures.
Per usage. You pay for what you consume: requests, bandwidth, compute seconds, build minutes. Platforms such as Railway and Fly.io lean on this model.
Per server. You pay for a machine, and what you run on it is up to you. This is how VPS providers work, and how Aria works, with the difference that Aria sets up and runs the server for you.
None of these is dishonest. They simply put the risk in different places.
Where the costs creep
Seats multiply quietly
When pricing is per seat, adding a contractor, a designer who sometimes deploys, or a new hire is a billing decision. Teams respond by sharing accounts or avoiding access, which is bad for security and for speed.
Everything is its own line item
A real application is not one thing. It is a web service, an API, a worker, a database and perhaps a cache. On a per-instance model each is billed on its own, and a database may cost as much as the app it serves.
Usage is hard to forecast
Bandwidth and request pricing is fair, but it is difficult to predict before launch. A good week can cost more than a quiet month. It also makes “how much will this side project cost?” hard to answer, which is a problem for freelancers quoting a client.
Environments multiply the bill
Staging and preview environments are good practice. On per-instance or per-project pricing, each one is more money.
A worked example, with assumptions
Here is a deliberately simple scenario, so you can see the shape of the argument. The numbers are placeholders for your own: always check each provider’s current prices.
Imagine a small team with:
- 3 people who deploy
- 1 web app, 1 API, 1 worker
- 1 Postgres database
- 1 staging copy of everything
On a per-seat plan you pay for three seats. On a per-instance plan you count six or so running units for production and staging, plus two databases. On a usage plan you pay for whatever the traffic does.
On a flat per-server plan you ask a different question: does it all fit in the server’s memory? If it does, the number on the invoice is the same whether three people or ten deploy, and whether the stack has four services or eight.
That is the trade. Flat pricing exchanges “pay for what you count” for “pay for the size of the box.”
How a flat price works at Aria
Each Aria plan is one dedicated cloud server that Aria sets up, hardens and runs for you. The price is one flat monthly amount per server. Draft prices start from £8 a month ex VAT, in GBP, from a UK company.
There are no charges per seat, per app, per database or per request. You run as many apps and databases as the server holds.
“As the server holds” is the real limit, and we would rather you know it up front. Memory is the constraint that matters. So Aria estimates it:
- Your coding agent reads your repository and writes one
aria.yamllisting services, databases and environment variables. - Aria validates the file and estimates how much memory the stack needs.
- Aria suggests the smallest plan that fits, then provisions the server and databases and deploys.
You see the number before you commit, instead of finding out at the end of the month.
Comparison of the models
| Per seat | Per instance | Per usage | Flat per server (Aria) | |
|---|---|---|---|---|
| You pay for | People with access | Each running unit | What you consume | One dedicated server |
| Adding a teammate | Costs more | Usually free | Usually free | Free |
| Adding another app | Usually free | Costs more | Costs more as it is used | Free if it fits in memory |
| Adding a database | Varies | Often costs more | Costs more as it is used | Free if it fits in memory |
| Forecasting | Easy for seats | Easy for steady load | Hard | Easy |
| Spikes in traffic | May add cost | Needs scaling | Add cost | Limited by the server’s size |
| Main risk | Access gets rationed | Many small bills | Surprise invoices | Outgrowing the server |
The last row matters. Flat pricing is predictable, but a server has a ceiling. If your stack outgrows it you will need a larger plan.
When flat pricing is not the right answer
- Spiky, global traffic. Usage-based platforms are designed to absorb sudden demand across regions. A single server is not.
- Tiny projects. If your whole site fits in a free tier, nothing beats free.
- Hard uptime contracts. If you need a formal service guarantee, check what a provider actually offers. Aria does not publish an uptime guarantee.
- You want zero server concepts. A fully managed platform hides servers entirely. Aria still gives you one, with the work done for you.
Questions to ask any provider
These help whichever model you choose:
- What happens to my bill if I double the team? Double the traffic?
- Is the database included, or billed separately?
- Do staging and preview environments cost extra?
- What is the unit I am actually paying for?
- Can I cap spending?
- If I leave, can I take my data and configuration with me?
FAQ
Is flat pricing always cheaper than per-seat pricing?
No. It depends on your team size, how many services you run and how much traffic you handle. Flat pricing tends to help when you run several services and databases or have several people deploying. For a very small, front-end-only site, a free tier may cost less.
What does “no per-app charge” mean?
You can run as many apps and databases as your server has room for, with no extra fee for each one. The limit is the server’s memory, not a count of apps.
How much does Aria cost?
One flat monthly price per server. Draft prices start from £8 a month ex VAT, in GBP. See the pricing page for the current plans.
What if I outgrow my server?
Aria estimates the memory your stack needs and suggests the smallest plan that fits, so you can size up front. Check the pricing page for how changing plans works.
Do I pay per request or per gigabyte?
No. Aria has no per-request charges.
See the numbers for your own stack
See our Heroku, Render and Railway comparison, view the full comparison table, see pricing, or get started.
Keep reading
A cheap Heroku, Render and Railway alternative on your own server
Why paying per dyno or per service adds up fast, and how running all your apps, workers and Postgres on one dedicated server keeps the bill flat.
Move from Supabase Cloud to your own server: a guided path
Leaving Supabase Cloud? See what moves with pg_dump, what doesn't (Storage, Auth secrets, Edge Functions), and how Aria guides the move to your own server.
A Vercel alternative where you own the server
Looking for a Vercel alternative? See how one dedicated server compares on price, databases and effort, and when Vercel is still the better pick.
Your own cloud. Without the DevOps.
One server that’s yours alone, set up and run by Aria, at one flat monthly price.