App Hosting: What It Is, How It Differs From Web Hosting, and What You Actually Pay For

App hosting is hosting for software that runs, as opposed to files that are served. A web host hands a browser HTML, CSS and images from disk. An app host runs your process, keeps it running, gives it a database and environment variables, and puts a route in front of it. If your project has a package.json with a start script, a requirements.txt, a Dockerfile, or anything that listens on a port, you need app hosting, and the rest of this post is about picking the right shape of it.

The search results for this term are mostly product pages, each describing its own product as if it were the category. That is not much use if you are trying to work out whether your project needs a container, a function, a virtual machine, or a static bucket with an API behind it. So this is the category, not a product: the four shapes app hosting comes in, what each one is good at, what the bill is made of, and the questions that actually decide it.

Table of contents

• Web hosting serves files, app hosting runs code
• The four shapes of app hosting
• What automatic scaling actually means
• What the bill is made of
• Do you need a server at all
• The questions that decide it
• How this fits the rest of the stack
• FAQ

Web hosting serves files, app hosting runs code

The distinction is not marketing. A web host takes a request for /about and returns the file called about.html. It does not need to know your language, does not run anything on your behalf, and can be scaled by copying files to more servers. That is why static hosting is cheap and why it barely ever goes down.

An app host takes the same request and hands it to a process you wrote. That process may query a database, call another service, render a template, or sit on a websocket for an hour. The host has to start the process, restart it when it crashes, keep its environment variables secret, route traffic to it, and know when it is healthy. Every one of those is a thing that can go wrong and a thing that costs money to do well.

The corpus already has a longer treatment of the decision tree in application hosting vs web hosting. The short version: a static site with a contact form that posts to a third party is web hosting. The moment a request needs your code to answer it, you are in app hosting, and the tools change.

The four shapes of app hosting

Almost every product in this category is one of four things wearing a logo.

1. A virtual machine. You get a Linux box with an IP address. You install the runtime, the reverse proxy, the certificate tooling, the process manager, and the database, and you keep all of it patched. Maximum control, maximum chores.
2. A platform, sometimes called PaaS. You push a repository; the platform detects the language, builds it, runs it, and gives it a URL. Databases and storage attach from a dashboard. You give up the shell and get back the evenings.
3. Serverless functions. Your code runs only when a request arrives, in a short-lived container, and you pay per invocation. Brilliant for bursty, stateless endpoints. Awkward for anything that holds a connection, keeps state in memory, or needs to start fast every time.
4. Containers you orchestrate. You package the app as an image and hand it to a scheduler. This is the shape large teams end up in, and the one that costs the most engineering time to run.

A first deploy of a real application, meaning one with a database and users, is nearly always best served by the second shape. The first is the one people choose because it looks cheapest, and the fourth is the one they choose because it looks serious. Both bills arrive later as time.

What automatic scaling actually means

Every product page in this category promises scaling. The word covers three different mechanisms, and it is worth knowing which one you are buying.

• Vertical scaling moves the process to a bigger plan: more CPU, more memory. It is the simplest and it has a ceiling. It is also what most small apps actually need, because the bottleneck is usually one slow query, not request volume.
• Horizontal scaling runs more copies of the process behind the same route. It requires the app to be stateless, or at least to keep its state in the database and not in a variable, and it multiplies the database connections, which is where it usually falls over first.
• Scale to zero stops the process when nobody is using it. It is what makes serverless cheap at low traffic, and it is what makes the first request after a quiet spell take two seconds.

The useful question is not whether a host scales but what bounds it. A platform that lets you set a floor plan and a ceiling plan, and moves between them on CPU, is one you can budget for. One that scales without limits is one that can surprise you at the end of the month, which is the polite word for it.

What the bill is made of

App hosting is priced in line items, and the process itself is often the smallest one. A realistic first production deploy has these parts, and each is a separate number:

• The runtime plan for the app. CPU and memory, usually monthly. This is the number on the product page.
• The database. A managed Postgres or MySQL instance on its own plan, with backups and a connection limit. Frequently the same price as the app, sometimes more.
• Persistent storage, if the app writes files. Uploads, generated PDFs, anything that has to survive a redeploy.
• Bandwidth. Included up to a threshold, then metered. Images and downloads are what push you over it.
• The parts that are free until they are not: build minutes, log retention, extra environments, team seats.

On RunxBuild a Node, Python, Go, Ruby, Java, .NET or Docker service runs from $4 a month on the Dev plan, a managed Postgres or MySQL sits beside it from the same ladder, and a static site includes 120GB of bandwidth before the $0.10 per GB kicks in. Those are real prices from the calculator, and the point of listing them is not that they are the only ones on the market but that they are the shape of the bill: three or four small numbers, not one.

Do you need a server at all

A surprising number of people searching for app hosting do not need it yet. A portfolio, a marketing site, a documentation site and most blogs are static, and static is cheaper, faster and harder to break. If the only dynamic part of the project is a form, post the form to a service and keep the site static. If the only dynamic part is a search box, index at build time.

You need app hosting when the request has to be answered by your code with data that changes: accounts, a dashboard, an API that other systems call, a checkout, an agent that runs on a trigger. The good news is that the line is not a wall. On a platform where a static site and a backend service live in the same project, you can start static and add the service on the day the form needs somewhere to send its submissions, without moving anything.

The questions that decide it

Ignore the feature grid and answer these, in order.

1. Does a request need my code to run? If no, use static hosting and stop reading.
2. Does the app hold state in memory or on disk between requests? If yes, functions are out; you need a long-running process and probably persistent storage.
3. Does it need a database, and who is going to back it up? If the answer to the second half is you, price your own time honestly.
4. What happens when a deploy goes wrong? A host with deploy history and one-click rollback turns a bad Friday into a bad ten minutes.
5. Can I read the logs of the build and the running app in the same place? A prototype without logs is a mystery with a URL.
6. What is the ceiling? Not the entry price: the plan you would be on with ten times the traffic, and whether you would need to leave to get there.

Answer those and most of the product pages either disqualify themselves or turn out to be the same thing at different prices. Then it is a matter of pushing the repository and reading the build log.

How this fits the rest of the stack

The reason app hosting feels expensive is that the product page shows one number and the bill shows four. The RunxBuild hosting calculator puts the service plan, the database, the storage and the bandwidth on one screen so you can see the whole shape before you commit to it, and change any line to see what moves. Ship the first version, connect the pieces, and keep the logs close.

Useful related references:

• Application Hosting vs Web Hosting: The Decision Tree, The Cost Difference, and The Traps
• Hosting for Startups: Pick What You Will Not Have to Leave
• What a Hosting Server Is, and Which Shape You Actually Need
• Services on RunxBuild

FAQ

What is the difference between app hosting and web hosting?

Web hosting serves files: the server returns HTML, CSS and images from disk and never runs your code. App hosting runs a process you wrote, keeps it alive, gives it a database and secrets, and routes requests to it. If a request has to be answered by your code, you need app hosting.

What is the cheapest way to host a web app?

Keep everything that can be static, static, and pay for a small runtime plan only for the part that has to run. A Node or Python service on a $4 Dev plan with a managed database beside it is a realistic floor for a real first deploy; the free tiers most platforms offer are for trying things, not running them.

Do I need a server to host an app?

Not a server you administer. A platform runs the process for you from a repository. You need something that runs your code, but that can be a managed service rather than a virtual machine you patch yourself, and for a first production deploy it usually should be.

How does app hosting scale automatically?

Either by moving the process to a bigger plan, by running more copies behind the same route, or by stopping the process entirely when idle. Ask which of the three a host does and what the upper bound is, because unbounded scaling is unbounded billing.

Which app hosting is best for Node or Next.js?

Any platform that detects the framework, runs the build, and gives you a live route with logs and rollback. The framework matters less than whether you can see the build log when it fails and roll back when the deploy is bad. Next.js in particular needs a runtime unless you export it statically.