The word "hosting" covers two very different jobs, and picking the wrong one is the reason a project stalls before it ships. A marketing site and a SaaS backend both need to live on the internet, but they need fundamentally different machinery underneath. One serves files. The other runs your code as a live process. Confusing the two leads to a login form that never authenticates or a database that has nowhere to connect.
This guide defines app hosting and web hosting in plain terms, compares them side by side, explains when each one is the right call, and shows where platform as a service (PaaS) fits as the modern default for anything with a backend.
The short answer: web hosting serves static files, HTML, CSS, images, and client-side JavaScript, over HTTP. App hosting runs a live server-side process, a Node, Python, Go, or .NET application, that executes code, talks to a database, and generates responses on every request. If your project only displays content, you need web hosting. If it does anything on the server, you need app hosting.
What Is Web Hosting?
Web hosting is a service that stores your website's files on a server and delivers them to browsers when someone visits your URL. The files are prepared ahead of time and served as-is. Nothing runs on the server to build each response. The classic examples are a static HTML site, a brochure page, or a front-end build output from a framework that has already been compiled to files.
A web host's core responsibility is simple: keep the files available and return them fast. Because the content does not change per request, a web host can cache aggressively, distribute copies across a content delivery network, and serve enormous traffic cheaply. There is no application state to manage and no code to keep alive between visits.
What web hosting handles
- File storage and delivery. Your HTML, CSS, images, and client-side JavaScript, served over HTTP.
- A domain and HTTPS. Pointing your address at the files and issuing a TLS certificate.
- Caching and CDN. Distributing static copies close to visitors for speed.
What web hosting cannot do
- Run server-side code. There is no persistent process to execute your business logic.
- Connect to a database from the server. Any data access has to happen from the browser or an external API.
- Hold session state or handle authentication server-side. Everything the server returns is the same for every visitor.
What Is App Hosting?
App hosting is a service that runs your application as a live, long-running process on a server and routes incoming requests to it. Instead of returning a fixed file, your code executes on every request: it reads input, queries a database, applies logic, and generates a response dynamically. This is what backs a login system, an API, a dashboard, a checkout flow, or anything personalized per user.
The Mozilla Developer Network draws exactly this line in its server-side programming overview: a static site returns the same hard-coded content to everyone, while a dynamic site generates responses on demand, which is what unlocks accounts, personalization, and storing user data. That "generates on demand" part is the entire job of an app host.
What app hosting handles
- A running server process. Your Node, Python, Go, Java, Ruby, PHP, .NET, or Rust application stays alive and listens for requests.
- Request routing and load balancing. Traffic is spread across one or more instances of your app.
- Server-side data access. Your process connects to a database and reads and writes on each request.
- Scaling. More instances start when traffic rises and stop when it falls.
- Environment configuration. Secrets and settings are injected at runtime rather than baked into files.
Because an app host runs code continuously, it has to solve problems a web host never touches: keeping the process healthy, restarting it after a crash, deploying a new version without dropping requests, and giving every instance access to the same database and secrets.
App Hosting vs Web Hosting: The Core Difference
The single distinction that decides everything else is whether code runs on the server per request. A web host returns pre-built files. An app host executes a live process. Every other difference in the table below flows from that one fact.
| Dimension | Web Hosting | App Hosting |
|---|---|---|
| What it serves | Static files (HTML, CSS, JS, images) | A live server-side process |
| Runs your code per request | No | Yes |
| Server-side database access | No | Yes |
| Best for | Landing pages, blogs, static site builds | APIs, SaaS, dashboards, dynamic apps |
| Languages involved | Client-side JavaScript only | Node, Python, Go, Java, Ruby, PHP, .NET, Rust |
| Scales by | Caching and CDN | Adding app instances behind a load balancer |
| State between requests | None | Sessions, in-memory data, live connections |
| Typical cost driver | Bandwidth and storage | Compute time the process consumes |
Needs PORT binding | No | Yes, the process listens on a port |
The practical test is one question: does your project need to do something on the server, or only show something? If a human could pre-generate every page you serve and nothing changes between visitors, web hosting is enough. The moment a response depends on who is asking, what they submitted, or what is in a database, you need app hosting.
Static Site vs Dynamic Application
The clearest way to internalize the difference is through the split between a static site and a dynamic application.
A static site is finished before anyone visits. A blog built with a static site generator, a documentation site, or a landing page compiles to a folder of HTML and assets. Every visitor gets identical bytes. Frameworks that produce a static export fall here too, even ones written in modern JavaScript, because the output is just files. Web hosting serves this perfectly and cheaply.
A dynamic application builds each response when the request arrives. A user signs in, sees their own data, submits a form, and the server writes to a database. This requires a process that stays alive, holds connections, and runs your logic. Server-side rendering, API routes, background jobs, and authentication all belong here. Web hosting cannot run any of it. You need app hosting.
The confusing middle ground is a modern full-stack framework. A framework like Next.js or Nuxt can produce a purely static export, which a web host serves, or run as a live server with server-side rendering and API routes, which requires app hosting. The deciding factor is not the framework. It is whether your build produces files or needs a running process.
Where PaaS Fits
For most teams in 2026, app hosting in practice means a platform as a service. A PaaS runs the servers, operating system, and runtime for you, builds your code, keeps the process alive, scales it, and hands you a database and HTTPS, all without asking you to manage infrastructure. It is app hosting with the operational burden removed. If you want the full model, see what is PaaS for how it compares to raw servers and finished software.
A PaaS collapses the app-versus-web decision into a single platform. Static output gets served fast, and dynamic code runs as a live process, from the same deploy. On Out Plane, you connect a Git repository and the platform builds and releases it. Both Cloud Native Buildpacks and a custom Dockerfile are supported, so a standard app deploys with zero configuration and a specialized one deploys exactly the way you define it. Supported languages span Node, Python, Go, Java, Ruby, PHP, .NET, and Rust.
The one rule that matters for any app host is how your process accepts traffic. Your server must listen on 0.0.0.0 and the port the platform provides, not localhost and not a hardcoded number. This is the most common reason a first deploy builds successfully but never receives requests.
// Bind to 0.0.0.0 and the platform-provided PORT
const port = process.env.PORT || 3000;
app.listen(port, '0.0.0.0', () => {
console.log(`App listening on port ${port}`);
});That single binding is the difference between a web host, which never runs your code, and an app host, which routes live traffic into it. From there, a PaaS adds what a dynamic app actually needs in production: managed PostgreSQL with automated backups, point-in-time recovery, read replicas, connection pooling, and pgvector handled for you; manual horizontal scaling where you run and adjust the number of instances yourself behind a load balancer; a custom domain with HTTPS provisioned and renewed automatically; and persistent volumes, so an engine like Redis runs self-hosted in its own container, plus TCP services, environment variables, access tokens, and a built-in terminal. If you are hosting a Node backend specifically, the Node.js hosting guide walks through the deploy in detail.
When to Use Which
- Use web hosting when your project compiles to files and nothing runs on the server. A marketing site, documentation, a portfolio, or a static front-end build. It is the cheapest and fastest option for pure content.
- Use app hosting when your project runs server-side code: an API, a SaaS product, a dashboard, an authenticated app, or anything that reads and writes a database on each request.
- Use a PaaS when you need app hosting without running infrastructure yourself, which is nearly always the right call for a team that wants to ship rather than operate servers. It handles both the dynamic process and any static assets from one deploy.
The cost profiles differ too. Web hosting bills mainly for bandwidth and storage, which stays cheap even at scale because the work is trivial. App hosting bills for the compute your process consumes, since the server is actually running your code. On Out Plane that is usage-based, pay-as-you-go billing, so you pay in proportion to real usage rather than a flat reserved amount. The Hobby tier stays permanently free with one app, and new accounts get $20 in trial credit with no credit card. For current rates, see /pricing.
Conclusion
App hosting and web hosting answer two different questions. Web hosting asks how to deliver files fast; app hosting asks how to run your code reliably. If your project only shows content, a web host is the simplest, cheapest path. If it does anything on the server, from authentication to a database write, you need app hosting, and in 2026 that almost always means a PaaS that removes the infrastructure work while keeping full control of your code.
Ready to deploy a dynamic app? Host your application on Out Plane with $20 in free credit and no credit card required.
Frequently Asked Questions
What is the difference between app hosting and web hosting?
Web hosting serves pre-built static files, HTML, CSS, and images, the same for every visitor. App hosting runs your code as a live server process that executes on each request, connects to a database, and generates responses dynamically. If your project only displays content you need web hosting; if it runs server-side logic you need app hosting.
Can I run a dynamic web application on regular web hosting?
No. Traditional web hosting only serves static files and cannot keep a server-side process alive or connect to a database from the server. A dynamic application that authenticates users, personalizes pages, or writes to a database needs app hosting, or a platform as a service that runs your code as a live process.
Is a PaaS the same as app hosting?
A PaaS is app hosting with the operational work removed. It runs your process the way any app host does, but it also builds your code, keeps it alive, scales it, and provides a managed database and HTTPS without you managing servers. On Out Plane you deploy from a Git repository and the platform builds and handles everything underneath.
Do I need app hosting for a static site?
No. A static site compiles to files and every visitor receives identical content, so web hosting or a CDN is the cheapest and fastest option. You only need app hosting when a response depends on who is asking, what they submitted, or what is stored in a database.
Which hosting do I need for a Next.js or full-stack app?
It depends on the build. A static export of Next.js or Nuxt is just files and runs on web hosting, while server-side rendering, API routes, or middleware require a live process and need app hosting. On Out Plane a server-rendered full-stack app deploys as a running process, and next start already reads the provided PORT, so no code change is needed.
Why does my app deploy but receive no traffic?
The most common cause is listening on localhost or a hardcoded port. A hosted app must bind to 0.0.0.0 and the port the platform provides through an environment variable so the load balancer can route requests to it. Fixing that one line is usually all it takes for traffic to reach your process.
Is app hosting more expensive than web hosting?
App hosting costs more per unit because the server actually runs your code, while web hosting mostly moves static files. But with usage-based billing you pay only for the compute your process consumes. On Out Plane the Hobby tier stays permanently free with one app, and there are no cold starts. For current rates, see /pricing.
Can I host both a static front end and a dynamic backend on one platform?
Yes. A platform as a service serves static assets fast and runs your dynamic backend as a live process from the same deploy, so you do not need to split them across two providers. Out Plane runs both, provisions a managed PostgreSQL database next to your app, and issues HTTPS on your custom domain automatically.