What is serverless? Functions vs long-running servers, explained
Kofi Agyem, Founder and CEO, CloudzyroPublished · 6 min read
On this page
Serverless runs your code only when a request arrives. How it differs from a long-running server, cold starts, costs, and when each is the better fit.
1. The short answer
Serverless is a way of running code where the platform starts your code only when a request or event arrives, runs it, then freezes or stops it, scaling the number of copies up and down for you. You pay for requests and run time instead of an always-on machine. The servers still exist; you just never manage them.
The alternative is a long-running server: your app starts once and keeps running, handling requests as they come. Both are good. They suit different apps, and the honest answer to “which is better?” is “for what?”.
2. How serverless functions work
You write a function that handles one request, such as an API route, and upload it. AWS describes the life of a Lambda function in three phases:
- Init: the platform sets up an environment, downloads your code and runs anything outside your handler, such as imports and connecting to a database.
- Invoke: it runs your handler for the request.
- Shutdown: when the environment is no longer needed, the platform shuts it down.
Between requests the environment is frozen, not running. If another request comes soon, the platform reuses it (a warm start). If not, the next request waits for a fresh one (a cold start). When traffic rises, the platform runs many copies at once without you doing anything.
Well-known serverless platforms include AWS Lambda, Vercel Functions, Netlify Functions and Cloudflare Workers. Each limits how long a function may run: Lambda runs invocations for up to 15 minutes by default, and Vercel's Hobby plan allows functions up to 300 seconds.
3. How long-running servers work
A long-running server is a program that starts once and listens for requests, such as a Node.js app with Express or a Next.js app run with next start. It stays in memory between requests, so it can keep database connections open, hold caches, run timers and keep connections to visitors open for real-time features.
You give it a fixed amount of CPU and memory. Most app hosts run it in a container and restart it if it crashes. Scaling usually means a bigger allowance, or more copies behind a load balancer.
4. Cold starts, in plain terms
A cold start is the extra wait when there's no warm environment ready. AWS's own documentation says cold starts typically occur in under 1% of Lambda invocations, and that their duration “varies from under 100 ms to over 1 second”. They're more common for functions that are called rarely, which is exactly the situation of a new site or a quiet admin page.
What makes cold starts longer is mostly in your hands: big bundles, lots of imports and heavy setup code. Smaller functions, loading libraries only when they're needed, and paid options that keep environments warm, such as Lambda's provisioned concurrency, all help.
A long-running server has no cold starts in this sense, as long as it stays running. Watch for hosts whose free plans put quiet apps to sleep, which brings back a similar wait: Render's free web services, for example, spin down after 15 minutes without traffic and take about a minute to wake.
5. Costs: how each is billed
Serverless is usually billed by requests and by run time multiplied by memory. AWS Lambda, for example, charges $0.20 per million requests plus a rate per GB-second, with a free tier of 1 million requests and 400,000 GB-seconds a month. Hosting platforms package this differently, often as included function invocations and CPU hours on each plan, then a price for more.
That model is excellent when traffic is low or very spiky: you pay almost nothing when nobody visits. It's harder to predict when traffic is steady and high, or when bots send a flood of requests, because every request costs something.
A long-running server is usually billed as a flat price for a set size, whether it's busy or idle. That's predictable, and often cheaper for steady traffic, but you pay for the capacity even at 3 a.m.
6. Pros and cons side by side
Serverless is good at:
- Scaling from zero to a sudden spike without planning.
- Costing next to nothing when idle.
- Small, independent jobs: webhooks, image resizing, form handlers.
- Running close to visitors, on edge platforms.
Serverless is harder for:
- Anything that runs for a long time or keeps a connection open.
- In-memory state: each request may reach a different copy, so caches and sessions must live elsewhere.
- Databases: many copies can each open their own connection and exhaust the database's limit. Use a connection pooler or an HTTP-based driver.
- Predictable bills when traffic is high and steady.
- Running exactly the same thing locally, since each platform has its own function format and limits.
Long-running servers are good at: steady traffic, persistent connections, in-memory caches, background timers, ordinary frameworks that run the same everywhere, and flat, predictable pricing.
Long-running servers are harder for: huge sudden spikes beyond the server's size, and paying for capacity you don't use.
7. Which should you choose?
- A static site: neither, really. Static files are served from a CDN on either kind of platform.
- A typical app or SaaS with steady users: a long-running server is simpler, runs every Node.js framework as-is and is easy to budget for.
- A few webhooks or scheduled jobs next to a static site: serverless functions fit well.
- Very spiky traffic, such as a ticket release: serverless scales out without planning, if your database can keep up.
- Real-time features, such as chat or live dashboards: a long-running server.
- Something built with AI: most AI tools produce either a static site or an ordinary Node.js app. Both run unchanged on a long-running server, so there's nothing to adapt.
8. How Cloudzyro runs apps
Cloudzyro runs Node.js apps as long-running servers, not serverless functions. Your app starts once, stays running and never sleeps, on the free plan too, so there are no cold starts from going quiet. Static files, such as images, CSS and JavaScript, are cached by Cloudflare close to your visitors.
Each site gets a fixed allowance: 1 CPU and 512 MB of memory on the free Launch plan, and 2 CPUs and 2 GB on Boost at $20 a month per site, with more CPU and memory available for Boost sites. A site that uses all its monthly traffic is slowed, never taken offline and never charged extra. There's no permanent disk, so data belongs in a database such as Supabase or Neon.
That's a deliberate trade-off. It suits apps with steady users and anyone who'd rather have a predictable bill. If your app is a handful of rarely used functions, a serverless platform may suit it better, and that's fine. See Sites & Apps, pricing and our comparisons of Vercel alternatives and Netlify alternatives.