Choose serverless hosting when your app is a website or a request and response web app with uneven traffic, because it scales by itself and there is no server to maintain. Choose a traditional always-on server or container when your app needs long-running processes, persistent connections, or full control over its environment.
We run software on both models. CaseCobra, our practice management product, runs as a Docker container on a host, with a CDN in front of it. Most of our other apps, including CoverageCobra, run on a serverless platform.
Neither choice was ideological. They are different tools, and the app usually tells you which one it wants. The trouble is that "serverless" is a poor name and the marketing around both models is loud, so business owners end up choosing on vibes.
This post explains what each model is, what each costs you in money and attention, and how we decide.
What is the difference between serverless and traditional hosting?
Traditional hosting gives you a server, or a container, that stays running all the time and waits for requests. Serverless hosting runs your code only when a request arrives, on machines the platform manages, then shuts it down again. With serverless you deploy functions and files. With traditional hosting you deploy a running program.
There are still servers in serverless. You just never see them, patch them, or size them.
The practical difference is what stays alive between requests. On a traditional server your program keeps running, so it can hold things in memory, keep a database connection open, run a background loop, or hold a live connection to a browser. On a serverless platform each request may land on a fresh copy of your code that knows nothing about the last one. Anything that must persist has to live somewhere else, such as a database.
When is serverless hosting the right choice?
Serverless hosting is the right choice for marketing websites, static sites, and web apps where each action is a short request and response: load a page, submit a form, save a record. It handles traffic spikes without planning, costs little when nobody is visiting, and leaves no operating system for you to update.
That describes most of what a small business needs. A static site is the extreme case: the pages are plain files, there is nothing to run at all, and the platform only executes code for the occasional form submission.
It also suits scheduled work. One of our internal tools reads a law firm's incoming email on a schedule, using the hosting platform's own scheduler to wake a function. Nothing sits idle between runs. We covered the options for scheduled jobs in what is a cron job.
The things we like most about serverless hosting are boring ones:
- Deploys are a push. Code goes to the repository and the platform builds and publishes it.
- Every change gets a preview address. We can look at a change on a real URL before it goes live.
- Scaling is not our job. A busy day and a quiet day need no decisions from us.
- There is no server to forget about. Nobody has to remember to apply security updates to a machine.
When is a traditional server or container the better choice?
A traditional server or container is the better choice when the app needs something that outlives a single request: long-running jobs, a process that holds state in memory, persistent connections, or software that has to be installed on the machine. It also suits apps with steady, predictable load.
CaseCobra is a Node application with a PostgreSQL database, packaged with Docker. A container gives an application like that one consistent environment that runs the same on a laptop and in production, and a process that stays up.
Serverless platforms typically put limits on how long a single request can run and how large a function can be. Those limits are fine for saving a form. They get in the way when a request needs to do slow, heavy work in one go. You can work around them with queues and background jobs, but at some point the workarounds cost more than a container would.
The trade is responsibility. With a container you choose the size of the machine, watch its memory, and decide what happens when it restarts. A managed container host handles much of that for you, and that is the kind of host CaseCobra runs on.
How do serverless and traditional hosting compare?
Serverless and traditional hosting differ most in how they bill, how they scale, and what they allow your code to do. Serverless charges for use and scales automatically but limits long-running work. Traditional hosting charges for a running machine and allows anything, but you plan capacity yourself.
| Question | Serverless platform | Always-on server or container |
|---|---|---|
| What you deploy | Files and functions | A running program |
| Billing model | Mostly by usage | Mostly a fixed charge for the machine |
| Idle cost | Low | The same as busy cost |
| Traffic spikes | Handled by the platform | Handled if you sized for them |
| Long-running work | Limited | Fine |
| State in memory | Lost between requests | Kept while the process runs |
| Database connections | Need a pooler or an HTTP driver | Ordinary connection pool |
| First request after idle | Can be slower (a cold start) | No delay |
| Upkeep | Very little | Some, less on a managed host |
We have not put prices in that table on purpose. Providers change their pricing often, and the right comparison is against your own traffic, so check current pricing pages before you decide.
Does serverless hosting change how you use a database?
Yes. Serverless code starts and stops constantly, so it cannot keep a steady pool of open database connections the way a long-running server does. Serverless apps usually connect through a connection pooler or a driver that sends queries over HTTP, and the database is often a hosted service built for that pattern.
This is the detail that surprises teams moving from one model to the other. We wrote about it in what is serverless Postgres.
Can you mix serverless and traditional hosting?
Yes, and many real systems do. A common arrangement is a static or serverless front end for the public site, a container for the part that needs to stay running, a hosted database, and a CDN in front of everything. Each piece runs where it fits best.
The cost of mixing is more places to look when something breaks. For a small product, one platform you understand well beats three you half understand. Add the second platform when the first one says no to something you need. A CDN is the exception: it sits in front of either model and is nearly always worth having.
Frequently asked questions
Is serverless hosting cheaper than a server?
For sites with low or uneven traffic it usually is, because you are not paying for a machine to sit idle. For an app with heavy, constant load, a fixed-price server can cost less. Compare both against your real usage, not a guess.
What is a cold start?
A cold start is the extra delay when a serverless platform has to start a fresh copy of your code because none was already running. It mostly affects the first request after a quiet period. Static pages are not affected, since no code runs to serve them.
Is a static website serverless?
In practice, yes. A static site is a set of files served from a CDN, with no application server running. Many serverless platforms host static files and functions together, so a static site with one contact form function is a very common setup.
Can I move from one model to the other later?
Usually, if the code keeps its state in a database and avoids features unique to one platform. Moving is real work, though, so choose for the app you have.
If you are not sure which model fits your project, describe what the app has to do and we will tell you where we would run it and why. Start a conversation.