# Serverless or your own servers: cost, cold starts and lock-in

URL: https://brainpowergroup.eu/en/blog/serverless-or-your-own-servers
Date: 2026-06-30 (updated 2026-08-05)
By: Aleksa, Brainpower Group

Serverless pays off with low or irregular traffic. Your own server wins with steady traffic, long-running processes or a lot of computation.

Serverless pays off when your traffic is low or irregular and you do not want to spend time on servers. Your own server, or a VM running containers, wins once traffic is steady, processes run long or you do a lot of computation. So look at the shape of your traffic first and at the technology second.

## Two cost curves

With serverless you pay per request and per unit of compute. AWS Lambda charges per request and per GB-second, measured from the moment your code starts until it returns. The free tier covers one million requests and 400,000 GB-seconds a month. Cloudflare Workers and Vercel count differently: there you pay for CPU time, and the time your code spends waiting on a database or an API does not count (on Vercel, memory is still billed during that wait). The paid Workers plan has a minimum of 5 dollars a month per account.

A server costs a fixed amount per month, whether it sits idle or runs flat out, so the price per request drops the better you use it.

So run the numbers with your own data. Take the requests per month, the average duration and the memory per function, and put that next to the smallest server that can handle your peak. For an API that mostly waits on Postgres or an LLM, the billing model matters a lot: do you pay for wall-clock time (Lambda) or only for CPU time (Workers, Vercel)?

## Cold starts show up in your p95 and p99

A cold start is the delay when the platform has to boot a new instance. You rarely see it in the average, but you do see it in p95 and p99. For a webhook or a nightly job it hardly matters, but for a checkout or a search box it does.

The fixes cost money. On Lambda, provisioned concurrency keeps instances warm, but you pay for that capacity for as long as it is switched on. On Google Cloud Run you do the same with minimum instances. With request-based billing an idle instance is charged at a lower rate, with instance-based billing at the full rate. Either way you pay for idle capacity again, which is what you wanted to get rid of with serverless.

Lambda bills the initialisation code outside your handler as duration. A heavy startup (lots of imports, a large SDK, opening connections) therefore shows up in latency and on the invoice. Vercel's Fluid compute reduces cold starts with bytecode caching and by pre-warming production deployments, and it lets several requests share one instance.

Before you pay for warm capacity, put the p99 per endpoint on a dashboard.

## The lock-in is in everything around the function

The function itself is usually ordinary code. The coupling sits in the triggers, the event formats, the permissions (IAM on AWS), the queues, the configuration and the way you collect logs and traces.

I recommend keeping the handler thin. It translates the event into a normal function call, and the business logic lives in modules that know nothing about the platform. You run those modules locally and in your tests without an emulator. Moving to a container then mostly means writing a new adapter.

Watch the hard limits as well. A Lambda function runs for at most 15 minutes and gets at most 10,240 MB of memory. On Vercel Pro the limit is 300 seconds by default and 800 at most (longer is only available in a beta). Long imports, video processing or connections that stay open for a long time fit poorly.

## Who carries the operational load

Serverless removes a lot of work: you do not patch an operating system and you do not plan capacity. Other work takes its place, though. You need an overview across dozens of functions and you need to know the concurrency limits (the default Lambda quota is 1,000 concurrent executions per region, and new accounts start lower). Database connections become a problem when hundreds of short-lived instances each open their own. At that point you need a connection pooler in front of Postgres.

With your own server you handle updates, TLS, monitoring, backups and scaling yourself. With Docker Compose on one or two VPSs that is manageable for a team of a few developers. When you need more is covered in [do you need Kubernetes](/en/blog/do-you-need-kubernetes).

## My rules of thumb

- Low or unpredictable traffic, short requests and nobody for operations: serverless.
- Steady traffic, long processes, lots of CPU or websockets: containers on servers.
- Mixed: the API in a container close to the database, with cron jobs, webhooks and event handling as functions.

Revisit the choice when your cloud bill or your traffic changes. [Keeping cloud costs under control](/en/blog/keeping-cloud-costs-under-control) describes how to run that monthly check. For Next.js on Vercel versus your own Docker host specifically, Bas wrote [Vercel or self-hosting](/en/blog/vercel-or-self-hosting).

## Where I start

For a new product I first ask four questions. What does the traffic look like over a day and over a week? How long does the longest job take? Where does the data have to live? And who gets the alert when something breaks? Once those are answered, the choice is usually quick. The stacks and platforms we work with are listed on our [technology page](/en/technology).

## Sources

- [AWS Lambda: quotas](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)
- [AWS Lambda: pricing](https://aws.amazon.com/lambda/pricing/)
- [Cloudflare Workers: pricing](https://developers.cloudflare.com/workers/platform/pricing/)
- [Google Cloud Run: minimum instances](https://docs.cloud.google.com/run/docs/configuring/min-instances)
- [Vercel: Fluid compute](https://vercel.com/docs/fluid-compute)
- [Vercel: Fluid compute pricing](https://vercel.com/docs/functions/usage-and-pricing)

## Frequently asked questions

**Is serverless cheaper than running your own server?**

With low or irregular traffic it usually is, because you pay per request and per unit of compute. With steady traffic or long-running processes a fixed server is often cheaper. Run the numbers with your own request volume, duration and memory.

**How do you avoid cold starts?**

You can keep instances warm with provisioned concurrency on AWS Lambda or minimum instances on Google Cloud Run. You pay for that capacity even when there is no traffic, so first measure whether cold starts actually hurt your p95 or p99.

**How long can a serverless function run?**

An AWS Lambda function stops after at most 15 minutes. On Vercel the default is 300 seconds, and on Pro you can raise it to 800. Longer jobs belong in a queue with a worker.

---

Source: https://brainpowergroup.eu/en/blog/serverless-or-your-own-servers
Brainpower Group, contact: https://brainpowergroup.eu/en/contact, hello@brainpowergroup.eu