Web hosting serves static files from disk to a browser. Application hosting runs a server-side process for every request, with state, with a database connection, and with code that executes between the request and the response. The choice between them is the choice between a brochure site and a SaaS product, and most teams pick the wrong side of it the first time. That is the practical answer. The cost answer is that the wrong pick is often an order of magnitude more expensive, either in overprovisioning or in engineering hours.
This post is for the founder, technical lead, or first engineer who has to pick a hosting model for a real product. It assumes you can read a Dockerfile, that you have a budget for monthly infrastructure, and that you would rather make the right call once than re-platform later.
Table of contents
- The one-line difference that decides everything
- Web hosting, in one sentence
- Application hosting, in one sentence
- The decision tree (with the questions that matter)
- The cost math nobody shows you
- The five traps that make the wrong pick hurt
- When to combine them (the modern architecture)
- What this looks like on a real PaaS
- The opinion this post is built on
- FAQ
The one-line difference that decides everything
The one-line difference: web hosting runs no code on the server. Application hosting runs your code on the server.
If that sentence is true for your product, you need web hosting. If it is not, you need application hosting. Every other consideration is downstream of that distinction.
The way to test it: open the request that your product makes for its most common action. Walk the path from the user’s browser to the response. If the path is “browser asks for a file, server sends the file,” you are doing web hosting. If the path is “browser asks for a thing, server runs code, code talks to a database, server sends the response,” you are doing application hosting.
Most teams confuse the two because the rendered HTML looks the same. The user does not care whether the page came from a file or from a database. The cost, the operational surface, and the failure modes are completely different.
Web hosting, in one sentence
Web hosting serves files. The browser asks for /about.html. The server reads about.html from disk and sends it. There is no code execution between the request and the response. The HTML, CSS, JavaScript, and images are exactly the bytes the team wrote or built.
A static site generator — Astro, Hugo, Jekyll, Next.js with output: 'export', Gatsby — produces a directory of HTML and assets that web hosting can serve. The build step runs once, at deploy time. The runtime is dumb on purpose.
The classic web hosting deployment is a directory uploaded to an S3 bucket and fronted by a CDN. The bucket stores the files. The CDN caches them at the edge. The browser gets the closest copy. There is no server to patch, no language runtime to update, no memory leak to debug.
Web hosting is cheap because there is no compute to bill. The cost is bandwidth and storage. The cost scales with traffic, not with complexity. A brochure site that gets 10,000 visitors a month is essentially free on web hosting. A SaaS dashboard that gets 10,000 visitors a month is essentially free on web hosting too, until it needs to log in.
Application hosting, in one sentence
Application hosting runs a server-side process per request. The browser asks for /dashboard. The server starts or reuses a process. The process executes the application code, talks to a database, reads from a cache, calls a third-party API, and produces a response. The response is dynamic — different per user, per state, per request.
A web framework — Express, FastAPI, Rails, Django, Gin, Spring — runs inside an application hosting platform. The platform provisions the language runtime, the memory, the CPU, and the network. The application code does the work.
Application hosting is expensive because there is real compute to bill. The cost is CPU time, memory, and uptime. A SaaS dashboard that runs 24/7 with 1 GB of memory is a real line item on the bill. The cost scales with traffic and with how long the process runs.
Application hosting also has a different failure surface. The process can crash. The database connection can drop. The memory can leak. The runtime can have a security CVE. Every team that runs application hosting learns the operational vocabulary: health checks, log shipping, autoscaling, secrets management, dependency updates.
The decision tree (with the questions that matter)
Walk the tree from the top. The first “yes” wins.
Question 1: Does the user’s request trigger any server-side code?
If no — web hosting. If yes — go to question 2.
Question 2: Does the response vary per user?
If no — web hosting. If yes — go to question 3.
Question 3: Does the response depend on a database?
If no — serverless functions or background workers are usually enough, but application hosting is the safest default. If yes — application hosting. Go to question 4.
Question 4: Does the response include server-side rendering of HTML?
If yes — application hosting with a Node, Python, Ruby, or Go runtime that supports SSR. If no — application hosting with a JSON API is enough; pair it with web hosting for the static frontend.
The tree collapses to two practical answers:
- Web hosting if every request can be served from a pre-built file.
- Application hosting if the response depends on user state, database state, or third-party APIs.
The trap is the modern SPA. A React app hosted on a CDN looks like web hosting. The login flow, the dashboard, the data fetches all hit an API somewhere else. The static frontend is web hosting. The API is application hosting. The product is both.
The cost math nobody shows you
The cost comparison that matters is not “$5/mo for shared web hosting” vs “$25/mo for an app server.” It is the cost over a year, including the things that go wrong.
Web hosting for a brochure site. 10,000 visitors a month, 50 MB of static assets. Cost: $0–$5/mo for the CDN, $0–$12/yr for the domain. The annual run rate is under $100. The operational overhead is “renew the domain once a year.” The cost of being wrong is “the site is slow.” The site being slow is fixable in an afternoon.
Application hosting for a SaaS dashboard. 1,000 active users, 1 GB memory, 0.5 CPU, runs 24/7. Cost: $25–$50/mo for the instance, $15–$30/mo for a managed Postgres, $5–$15/mo for object storage and email. The annual run rate is $540–$1,140. The operational overhead is “patch the runtime, monitor the database, rotate the secrets, fix the memory leak.” The cost of being wrong is “the app is down.”
Wrong pick #1: web hosting for a SaaS. The team picks web hosting because it is cheap, then realizes the dashboard cannot log in, the form cannot persist, the data has to live somewhere. The result is a Frankenstein: a static frontend that talks to a managed database through a serverless function that gets called from a webhook. The cost is the same as a real application hosting setup, plus the engineering hours to keep the pieces glued together.
Wrong pick #2: application hosting for a brochure site. The team picks application hosting because they assume they will need it. The result is a Node process that serves three HTML files. The cost is $25/mo to run a process that a CDN would serve for free. The operational overhead is “keep the process alive.” The cost of being wrong is $300 a year for no reason.
The right pick saves money immediately. The wrong pick costs money for as long as the product is live.
For a PaaS like RunxBuild, the hosting calculator shows the real numbers — instance type, memory, CPU, storage, database, traffic — for both hosting models side by side. The comparison is honest because both hosting models are first-class on the same platform.
The five traps that make the wrong pick hurt
Trap 1: Treating the SPA as web hosting. A React app served from a CDN is web hosting for the bundle, but the bundle cannot do anything without an API. The team that ships the SPA without the API has a brochure site with a login button that does not work. The fix is to plan for both from day one.
Trap 2: Treating dynamic pages as web hosting. A marketing site with a contact form, a pricing calculator, or a waitlist signup is not pure web hosting the moment it accepts input. The form’s input has to go somewhere, and the somewhere is application hosting (or a serverless function, which is application hosting with a different billing model).
Trap 3: Treating server-rendered React as web hosting. Next.js, Nuxt, and SvelteKit produce HTML on the server when configured for SSR. The HTML looks like a static file. The runtime is not a static file. The runtime is application hosting.
Trap 4: Forgetting the database. Every application hosting decision has a database decision attached. The cheapest application hosting setup that talks to a managed Postgres is the right answer. The cheapest application hosting setup that uses SQLite on the server’s filesystem is not — the database file is ephemeral and the data is gone on the next deploy.
Trap 5: Forgetting the secrets. Application hosting runs real code, which means real API keys, real database credentials, and real signing secrets. The wrong pick (committing secrets to the repo, sharing them in Slack, putting them in environment variables on a developer laptop) is a security incident waiting to happen. The right pick is a secrets manager and environment variables wired into the deploy.
When to combine them (the modern architecture)
The modern architecture combines both: web hosting for the static frontend, application hosting for the dynamic backend. The two deploy independently. The two scale independently. The two have different failure modes.
A typical architecture:
- Web hosting layer. A React, Vue, or Svelte SPA. Built at deploy time, served from a CDN. No server-side logic.
- Application hosting layer. A Node, Python, Ruby, or Go API. Runs as a long-lived process. Connects to a managed Postgres. Talks to third-party APIs.
- Database. A managed Postgres or MySQL. Backed up. Replicated. Sized for the working set.
- Object store. S3 or equivalent for uploads, exports, generated files. The application writes to it; the CDN reads from it.
- CDN. Cloudflare, Fastly, or the platform’s built-in edge. Caches the static frontend and serves it from the closest point of presence.
The architecture is the same shape regardless of which framework you pick. The advantage is that the static frontend is cheap to host (a CDN) and the dynamic backend is sized for actual API traffic. The two do not have to scale together.
For a solo founder shipping an MVP, the architecture is overkill. The right pick is application hosting with a server-rendered framework (Next.js with SSR, Rails, Django) and a single managed database. The combined architecture is the right pick for a team that has separate frontend and backend engineers, or for a product that has clearly different scaling profiles for the two layers.
What this looks like on a real PaaS
On a platform like RunxBuild, the hosting model is a config choice, not a platform choice.
- Web hosting is the static site service. Connect a Git repo, pick a build command (
npm run build), and the platform builds, deploys, and serves the output from a CDN. No server, no runtime to manage, no bills beyond bandwidth. - Application hosting is the web service. Connect a Git repo, pick a runtime (Node, Python, Ruby, Go, Rust, Java), and the platform provisions the instance, the database connection, the environment variables, and the health checks. The cost is the instance size plus the database plus the egress.
- Both is two services in the same workspace. The static site is the frontend. The web service is the backend. The two share the domain (the static site serves
/, the web service serves/api/*).
The model matters because the cost math is honest. The platform charges for what each service uses, not for a bundle that includes both. A brochure site on the platform is essentially free. A SaaS dashboard on the platform is the real cost of the application hosting layer, no markup.
The opinion this post is built on
The opinion is that the web hosting vs application hosting decision is the highest-leverage infrastructure call a team makes in the first six months. The wrong pick is recoverable but expensive. The right pick is invisible.
A useful exercise: open the most expensive service in your infra bill and ask whether it could be a static file. If yes, move it. Then open the cheapest service and ask whether it is actually running code on the server. If yes, stop paying for the static tier and start paying for the application tier. The hosting bill drops, and the operational surface gets honest.
FAQ
What is the difference between web hosting and application hosting?
Web hosting serves static files. Application hosting runs server-side code per request. Web hosting has no runtime to manage and no compute to bill. Application hosting has a runtime, a process, a database connection, and a real line item on the bill.
Which is cheaper, web hosting or application hosting?
Web hosting is cheaper for the same traffic because there is no compute to bill. The cost scales with bandwidth and storage. Application hosting is more expensive because it scales with CPU, memory, and uptime. The right pick is the one that matches the product; the wrong pick costs money for no reason.
Can I host a SaaS product on web hosting?
Only the static frontend. The login flow, the dashboard, the data fetches, and the user state all require application hosting or serverless functions. A SaaS product on pure web hosting is a brochure site with a broken login button.
Can I host a brochure site on application hosting?
Yes, but you are paying for a process you do not need. A Node server that serves three HTML files costs $25/mo on application hosting and $0 on web hosting. The wrong pick is $300 a year for the same result.
What is the right hosting for a marketing site?
Web hosting. The site is built once at deploy time and served as static files. There is no server-side logic per request. A CDN serves the files from the closest point of presence. The cost is bandwidth and storage, not compute.
What is the right hosting for a SaaS dashboard?
Application hosting for the API, web hosting for the static frontend, and a managed database for the state. The two services scale independently. The database is sized for the working set.
What about serverless functions?
Serverless functions are application hosting with a different billing model. The function runs on demand, the platform bills per invocation and per GB-second, and there is no process to manage between invocations. The right pick for small, infrequent, event-driven work. The wrong pick for high-traffic, long-running APIs (the per-invocation cost adds up).
What is the difference between a static site generator and a web framework?
A static site generator (Astro, Hugo, Jekyll, Next.js with output: 'export') produces HTML at build time. The runtime is web hosting. A web framework (Next.js with SSR, Rails, Django, FastAPI) produces HTML at request time. The runtime is application hosting. The choice between them is the choice between web hosting and application hosting.
How do I know if I picked the wrong hosting?
The wrong pick shows up in three places. The bill is higher than the traffic justifies. The engineering team is spending time on infrastructure that does not match the product. The site is slow for no good reason. Any one of the three is a signal to revisit the decision.
What is the cost of web hosting vs application hosting in practice?
Web hosting for a brochure site is under $100 a year. Application hosting for a SaaS dashboard is $500–$1,500 a year for the same traffic, plus the database and the operational overhead. The wrong pick is the higher number with no matching benefit.
Can I switch from web hosting to application hosting later?
Yes, but the migration cost grows with the product. A brochure site that needs a contact form can add a serverless function in an afternoon. A SaaS dashboard that started on web hosting has to be re-platformed. The right pick on day one is cheaper than the migration cost on day 100.
How does RunxBuild support both hosting models?
RunxBuild has first-class services for both. Static sites deploy from a Git repo to a CDN. Web services deploy from a Git repo to a long-lived process with a managed database. The two coexist in the same workspace, share the same domain, and bill separately. The hosting calculator shows the cost difference side by side.