A Hosting Calculator Is Only Useful If It Counts Everything

The number people quote for hosting is almost always the compute plan, and the compute plan is rarely more than half of what a running project costs.

Ask what it costs to host a site and you get a plan price. That answer is correct and incomplete in a specific, repeatable way: it prices the box and omits the database, the bandwidth, the storage, the second environment, and the renewals. Those omissions are why the first real bill is a surprise, and they are entirely predictable, which means you can just count them.

What a plan price actually covers
The six line items estimates usually miss
How to size compute without guessing
Estimating bandwidth without a spreadsheet
Working an example end to end
Reading a bill after the first month
How this fits the rest of the stack
FAQ

What a plan price actually covers

A hosting plan buys you a slice of a machine, described as some amount of vCPU and some amount of RAM, and the right to run one thing on it. That is genuinely most of the cost for a simple site, and for a static marketing page it may be nearly all of it.

It stops being most of the cost the moment the project has any of the following: a database, user uploads, a background worker, a staging environment, or meaningful traffic. Each of those is a separate line, and each is easy to forget at estimation time precisely because none of them existed when you were building locally.

So the useful mental model is not what plan do I need. It is what components will be running, and what does each one cost. The plan is one of them.

The six line items estimates usually miss

In rough order of how often they cause a surprise.

The database. It runs on its own resources, whether that is a managed instance you pay for separately or memory taken out of the same box as your app. Either way it is not free, and putting it on the same small instance as the application is how both end up slow.
Bandwidth and egress. Data leaving the platform. Usually there is an included allowance and a per-gigabyte rate beyond it. It is invisible until you serve images or video, and then it is not.
Persistent storage. Uploads, generated files, backups. Container filesystems are ephemeral, so anything that must survive a deploy needs a volume or object storage, which is priced by what you keep.
Non-production environments. Staging is a second copy of production, at some size. Teams routinely price production carefully and then run a staging environment they never counted.
Background workers and scheduled jobs. A queue consumer or a cron job is another process that needs somewhere to run. If it is not sharing the web service, it is another line.
Renewals that are not monthly. The domain, mostly. Cheap for a year and then not, which is a real annual cost even though it never shows up on a hosting bill.

Add those up before you commit and the number is boring. Discover them one at a time over three months and it feels like the platform is nickel-and-diming you, when in fact the estimate was just short.

How to size compute without guessing

The two numbers to establish are memory, which is a hard floor, and CPU, which is a throughput question.

Memory first, because getting it wrong is not a slowdown, it is a crash. Run the application locally under a realistic load and watch resident memory. Take the steady-state figure, add whatever concurrency multiplies it by, and add headroom. If the process gets killed for exceeding its limit, the platform restarts it and you get an outage rather than a slow page.

CPU next. Most small web applications are not CPU-bound; they spend their time waiting on a database or an external API. Half a vCPU handles a surprising amount of traffic for that shape of workload. The exceptions are real and easy to identify: server-side rendering, image processing, and anything doing model inference are all genuinely CPU-hungry and should be sized generously.

The practical approach is to start one step above your measured floor and watch. Moving up a plan takes a minute; recovering from a week of intermittent out-of-memory restarts takes longer and costs more in confidence than in money.

Estimating bandwidth without a spreadsheet

Bandwidth is the line item people find hardest to predict, and it is actually the easiest, because it is one multiplication.

monthly transfer = average page weight x page views per month

A 2MB page at 50,000 views is about 100GB. A 500KB page at the same traffic is 25GB. The lever is page weight, and page weight is nearly always images.

Three things move the number materially. Serving images in a modern format at the size they are displayed rather than at their original dimensions typically cuts total page weight by more than half. Caching headers mean repeat visitors do not re-download assets at all. And a CDN in front of the origin serves the cached copy from the edge, which both speeds things up and takes the transfer off your origin’s bill.

Video is the exception that breaks the arithmetic. A few minutes of video at reasonable quality is tens of megabytes per view, and self-hosting it turns bandwidth from a footnote into the largest line on your bill. If the project has video, price that separately and deliberately.

Working an example end to end

A small SaaS application, to make it concrete. An API service, a Postgres database, a background worker, a static marketing site, and a staging environment.

API service. Measured at 400MB resident under load, not CPU-bound. A 1GB plan with room to grow, so around $13 a month on the general ladder.
Database. Small dataset, low query volume, but it must not be starved. A 1GB instance beside the app, again around $13.
Background worker. A separate small process handling emails and scheduled jobs. A Dev plan at $4 covers it comfortably.
Static marketing site. Build output on a custom domain, with 120GB of bandwidth included, so effectively no compute cost at this traffic.
Staging. The same three services at the smallest plans, used a few hours a day. Roughly $10 to $12 if it runs continuously, less if it does not need to.
Domain. One renewal a year, which is a small annual number and worth writing down so it is not a surprise.

Around $55 a month for the running project, with the largest single component being the pair of 1GB instances. The point of the exercise is not the total, which will differ for your project. It is that six numbers you can defend beat one number you guessed.

Reading a bill after the first month

The estimate is a hypothesis. The bill is the measurement, and comparing them is a ten-minute job that pays for itself.

Look for a line you did not predict. That is the item your model was missing, and it will keep growing until you account for it.
Compare bandwidth against your page-weight arithmetic. A large gap usually means uncached assets or something serving images at full resolution.
Check whether anything is idle. A staging environment that runs continuously for a team that uses it two hours a day is the most common piece of pure waste.
Check whether anything is starved. Restarts in the runtime logs, or a database at its connection limit, are the platform telling you a plan is undersized before your users do.

Do that once and your estimates stop being guesses. Do it every few months and the bill stops being a surprise entirely.

How this fits the rest of the stack

This is exactly the exercise the RunxBuild hosting calculator is built for: it puts the service, the database, the storage, the worker, and the bandwidth on screen as separate numbers so the total is something you assembled rather than something you accepted. The plan ladder it prices is the real one, starting at $4 for a Dev instance and $6 for Basic, with static sites carrying 120GB of bandwidth included and $0.10 per gigabyte after that. Worth running before you build, and worth running again after the first bill, because the gap between the two is the most useful thing you will learn about your own project this month.

Useful related references:

FAQ

What does website hosting actually cost per month?

It depends entirely on what is running. A static site with modest traffic can cost nothing beyond a domain renewal. An application with a database, a worker, and a staging environment is typically several small plans added together. The plan price for the application is usually less than half the total, which is why single-number estimates are consistently low.

What do people forget when estimating hosting costs?

Six things, reliably: the database, bandwidth and egress beyond the included allowance, persistent storage for uploads and backups, non-production environments, background workers and scheduled jobs, and the annual domain renewal. Each is easy to overlook because none of them exist while you are developing locally.

How do I estimate bandwidth usage?

Multiply your average page weight by monthly page views. A 2MB page at 50,000 views is roughly 100GB. Page weight is dominated by images, so serving them at display size in a modern format usually halves the figure. Self-hosted video breaks this arithmetic entirely and should be priced on its own.

How much CPU and RAM does my app need?

Measure rather than guess. Run the application under realistic load and note resident memory, then add headroom, because exceeding a memory limit is a crash rather than a slowdown. Most small web apps are not CPU-bound and run fine on half a vCPU; server-side rendering, image processing, and model inference are the genuine exceptions.

Why was my first hosting bill higher than expected?

Almost always a line item the estimate omitted rather than a rate that changed. Compare the bill against your model and find the entry you did not predict. The usual culprits are bandwidth from uncached images, a staging environment running around the clock, and storage that has been accumulating backups since launch.