Two billing models
A serverless function platform charges for what runs: invocations, execution time multiplied by allocated memory, and usually egress. Idle costs nothing. A VPS charges a flat rate for a machine that's always on, idle or busy. A FastNode Spark is $5 a month whether it handles one request or ten million.
That difference makes the decision mostly arithmetic once you know your traffic shape. Estimate requests per month, average duration and memory, plug them into the provider's calculator, and compare against the smallest server that would handle your peak. Then add the costs that don't appear in the calculator, which is where the rest of this page comes in.
Where serverless wins
- Spiky, rare work. A webhook that fires a few times an hour, a nightly report, a form handler on a low-traffic site.
- Massive, short bursts. Fanning out thousands of parallel tasks for a minute, then nothing.
- No server to patch. The platform owns the OS and runtime. If nobody on the team wants to run Linux, that matters.
- Tight integration with a provider's queues, storage triggers and identity system, if you're already deep in one ecosystem.
Where a VPS wins
- Steady load. Once a service is busy most hours of the day, flat pricing usually beats per-request pricing, often by a wide margin.
- Long-lived connections. WebSockets, server-sent events, gRPC streams and database connection pools all assume a process that stays up.
- Local disk. SQLite, build caches, uploaded files being processed, a search index: functions get scratch space that vanishes; a server keeps its NVMe.
- Long jobs. Functions impose maximum execution times. A server will run a three-hour migration if you ask it to.
- Your choice of everything. Language version, system packages, background daemons, cron, a sidecar proxy. No runtime allow-list.
- Predictable bills. A traffic spike or a retry storm can't multiply your invoice.
Cold starts and latency
When a function hasn't run recently, the platform has to provision an execution environment, load your code and initialise the runtime before handling the request. That's a cold start. Its cost varies widely by runtime and package size: interpreted languages with small bundles start quickly, large dependency trees and JVM-style runtimes take longer. Keep-warm tricks and provisioned concurrency reduce the effect, at a price that starts to look like a server.
A process on a VPS is already loaded, connections are already open and caches are already warm. The first request after a quiet period is as fast as any other. For UK users, a London server also keeps the network part of the latency short; see the London page.
State
Functions are stateless by design. Anything that survives between invocations goes into an external store: a managed database, a cache, object storage. Each of those is another service, another bill and another network hop on the request path. Connection-heavy databases need a pooling layer, because hundreds of short-lived functions opening their own connections will exhaust a database quickly.
On a server you can keep state where it's cheapest: in memory, on the local disk, or in a database on the same machine or the one next to it. That's simpler right up until you need more than one server, at which point you adopt the same external-state patterns, on your own terms.
Operations
| Task | Serverless | VPS |
|---|---|---|
| OS patching | Platform | You (unattended-upgrades or dnf-automatic help) |
| Scaling | Automatic, per request | You: bigger plan, more servers, a load balancer you run |
| Local debugging | Emulators, often imperfect | Same process you run locally; SSH in when needed |
| Observability | Platform logs and traces | Your choice of tools, on your server |
| Lock-in | Triggers and config tied to one provider | A Linux box; move it anywhere |
When a FastNode server is the wrong answer
If your workload runs a few minutes a day, a server sits idle the rest of the time and you're paying for that. If you genuinely need to absorb a hundredfold spike with no warning and no queue, automatic scaling is worth paying for and we don't offer it. If your users are mostly outside the UK, a single London region adds distance. And if nobody on your team wants to own an operating system, managed platforms exist for a reason.
A sensible hybrid
Run the steady core on a server: API, workers, database, cache. Keep functions for the rare and bursty edges. A Boost with 2 vCPU and 4 GB handles a surprising amount of API traffic; the API backends page walks through sizing. Compare all plans on the pricing page.