In this article you will learn:
- where you can host a website and what it costs (short version: less than you think)
- the difference between a website and a web app — and why it decides your long-term bill
- the three budget tiers of hosting, from free to "call our sales team"
- why a web app is never just one thing to host
A website can sit on the internet for free, indefinitely. A web app starts running up meters (more often than not) the moment it goes live.
The confusing part is that both are called "hosting", both end with a URL, and yet the invoices look nothing alike. This post answers the two questions people actually type into a search bar — where can I host this and what will it cost me — and shows the one distinction that decides both answers before any provider does.
TL;DR
If you just want the conclusion:
- Static site (portfolio, blog, docs): host it for free on GitHub Pages, Cloudflare Pages, or Netlify. Done. You can stop reading pricing pages forever.
- Site with a CMS (WordPress and friends): a few dollars a month on shared or managed hosting. You are technically running a small app — but somebody else wrote it and mostly runs it for you.
- Web app (anything with a login, upload, or payment): you are not hosting one thing. An app is a set of layers working together, each hosted — and billed — separately. Budgets start around $5/month and grow with usage, plus the least visible cost: your own maintenance time.
The rest of this post unpacks each bullet, from general to specific.
Website or web app? Answer this first
Before comparing providers, answer one question: is your project a static set of files the browser simply displays, or a running system that changes over time in response to user interaction?
A static site is prepared entirely ahead of time, and it is only the frontend — one layer, nothing behind it. The server's job is to find a file and send it, a problem so solved that CDNs do it globally, instantly, and mostly for free. A web app runs code on every request: it checks who you are, reads a database, and builds the answer live. That means a computer somewhere must keep your code alive 24/7 — and computers that stay alive send invoices.
Between those two sits the classic middle ground: a website powered by a CMS. Technically it is a small web app — WordPress is code plus a database — but you didn't write it, and for a few dollars a month your host mostly runs it for you. It deserves its own column, because its costs and failure modes sit exactly between the other two:
💡 Click a row to see why the columns differ.
A huge share of the web does not need a backend. If your project fits the first or second column, the next section is genuinely all you need. If it fits the third, read the next section anyway — then keep going, because your answer has more than one line.
Where can you host it, and what does it cost?
Here is the short, concrete part. Hosting is a sliding scale of budget and responsibility, not a ladder of quality — drag the slider from $0 to "sky is the limit" and see what each stop buys:
Zero dollars, real hosting. The catch is always in the limits, not the price.
💡 Click a row to get more details.
You may have noticed the names of hosting models hiding in that figure: shared hosting (one server, many tenants), VPS (a virtual machine you rule — and patch), PaaS (you push code, they run it), serverless (you upload functions, they bill per execution), cloud (all of the above, sold as Lego bricks). For a website, you don't need to study them — the figure already made the choice cheap. For an app, choosing between those models is a real decision with real trade-offs, big enough that it gets its own part later in this series.
One more honest note on costs, because "from ~$5/mo" hides a pattern. What you actually pay for is: compute that stays awake, a database that never forgets, bandwidth, and — the meter nobody prints on a pricing page — your time. A static site avoids nearly all four. A web app runs all of them, forever. That is why the website/app fork from the previous section matters more than any provider comparison: it decides which meters exist at all.
That figure settles websites. Web apps deserve one more section — because an app is not one thing to host.
A web app is not one thing to host
For a static site, the story ends with the table above. A web app is a set of layers working toward a single goal — delivering value to a user who interacts with the program through a web interface. The frontend is still there, but it is now the visible tip of a running system:
What the user sees and clicks.
The presentation layer: HTML, CSS, and JavaScript delivered to the browser. It can be plain files generated ahead of time (the static-site case) or rendered per request on a server.
The business logic answering requests.
The layer that computes answers: validates input, applies rules, talks to the database, calls other services. It is also the layer with the most hosting options — which is a problem, not a luxury.
Data that must survive restarts and deploys.
Databases, file storage, caches. The only layer you cannot redeploy your way out of: code is replaceable, your users' data is not. Backups belong here from day one.
UI — What the user sees and clicks.
Backend / API — The business logic answering requests.
Persistence — Data that must survive restarts and deploys.
💡 Hover over/tap a layer to see extra deatils.
The point of this picture is not the individual layers — the series page walks through them, and each gets its own dedicated part. The point is what the stack means for the two questions this post started with: each layer can be hosted separately, by a different provider, with a different pricing model. "Where do I host my app" has no one-line answer because it is really three questions wearing a trench coat — and your long-term cost is the sum of the layer meters, plus the maintenance time nobody invoices you for.
NOTE
For clarity, the stack above is a simplified view of a web app. A real app may have more layers (e.g., caching, message queues, search engines) and more complexity (e.g., multiple frontends, multiple backends) — the same logic simply applies to more pieces.
Also, you might pick one provider that handles more than one layer (e.g., AWS, GCP, Azure, or Vercel). That can be more cost-efficient and more performant — and often just handier, because one platform with one dashboard and one invoice is easier to manage than a separate provider for every layer. Mixing and matching stays an option, not an obligation.
What's next
This post is part 1 of the Web App Hosting, Layer by Layer series. Next up: the UI layer — static hosting, CDNs, SSG vs SSR vs edge, and the exact moment "static" stops being enough. And the layers are only half the story: shipping, securing, running, and watching an app in production have their own map, which lives on the series page.
