Hosting decisions get made by tier and price. The useful question is what has to execute when a request arrives.
The four levels
Static files. Nothing executes. The server returns a file. Frequently free, extremely fast, effectively unbreakable, no maintenance.
Static plus functions. Mostly files, with short server-side handlers for the few things that need one. Scales to zero, no machine to manage.
Managed container runtime. Your application runs continuously. You supply the image; the platform handles the machine, the certificates and the scaling.
A machine you administer. Complete control, and you own the operating system, the patching and the monitoring for as long as it exists.
| Level | Runs | You maintain |
|---|---|---|
| Static | Nothing | Nothing |
| Functions | Short handlers | Your code |
| Container | An application | Image and dependencies |
| Machine | Anything | The whole system |
Default to the lowest that works
Most projects presented as needing a server do not.
A documentation site, a marketing site, a portfolio, a dashboard over data known at build time, a tool that runs in the browser. All static, all free, all with nothing to patch.
Moving up a level later is straightforward, because the content and the code are unchanged. Moving down after building against a machine effectively never happens, because assumptions about a persistent filesystem and long-running state spread through the code.
Where functions fit
Short, stateless work.
A form handler, a webhook receiver, an endpoint that signs an upload, a small API putting a key in front of a third-party service so it is not in the page.
They start on demand and cost nothing when idle. The constraint is execution time and the absence of local state, which is exactly the constraint that keeps the design clean.
Signals to move up
To functions: you need a secret that cannot be in the page, or a form that must reach something other than a mail service.
To a container: the application has to run continuously, holds connections, or has a startup cost you cannot pay per request.
To a machine: something must run on a schedule at the system level, a process must stay alive holding state, or the software expects to own the system.
Anything short of those signals is a level you are paying for and maintaining without needing it.
The cost that is not on the invoice
Maintenance, and it only grows.
A static site left alone for three years still works. A machine left alone for three years is a liability with known vulnerabilities, and somebody has to care about it every month in between.
Count that before choosing the level that gives you the most control.
Closely related: How to host a website, and Should you host a site yourself? for the adjacent problem.
Put it at an address
Write down what has to execute at request time, default to static, add functions for short stateless work, take a container for a real application, and take a machine only when something genuinely requires one.