What Is Serverless? (There Are Still Servers)

"Serverless" is one of the most misleading names in tech. There are servers. You just don't manage them, see them, or pay for them when nothing is happening. Whether that's a good deal depends on what your app does.

Two ways to run code

A traditional server is always on. Your app starts, listens for requests, and keeps running — whether it gets a thousand visitors an hour or none. You pay for it around the clock. (What Is a Server?.)

Serverless runs your code only when a request arrives. The platform starts a copy of your function, runs it, returns the response, and may shut it down shortly after. Many requests at once? It starts many copies. No requests? Nothing runs, and you pay nothing (or close to it).

Examples: AWS Lambda, Google Cloud Run functions, Azure Functions, Cloudflare Workers, Vercel Functions, Netlify Functions, Supabase Edge Functions.

What serverless code looks like

Instead of a whole server, you write functions — one per endpoint or task:

// api/hello.js
export default async function handler(request) {
  return new Response(JSON.stringify({ message: "Hello!" }), {
    headers: { "Content-Type": "application/json" },
  })
}

The platform handles the rest: routing requests to it, scaling it, HTTPS, and logging.

The good parts

No server to maintain. No operating system updates, no crashed processes to restart.
Scales automatically, from zero to large bursts.
Pay per use. Great for apps with spiky or low traffic — a side project with ten visitors a day can cost nearly nothing.
Fast to deploy. Push code, get endpoints.

The catches

Serverless has trade-offs that surprise people, often after launch.

Cold starts

When a function hasn't run in a while, the platform has to start a fresh copy before handling the request. That cold start can add anything from a few milliseconds to a couple of seconds, depending on the platform, language, and how much code is loaded. Users notice it as an occasional slow first request.

Time limits

Functions have a maximum run time — often seconds to a few minutes, depending on the platform and plan. Long jobs like video processing, big imports, or a slow AI generation can hit the limit and be cut off. (Your App Needs Background Jobs.)

No memory between requests

Each invocation may run in a fresh copy. You can't keep data in a variable between requests, can't rely on files written to local disk, and can't keep a background process running. State must live in a database, cache, or storage service. (Where to Store User Uploads.)

The database connection problem

Traditional databases like PostgreSQL expect a modest number of long-lived connections. Serverless can start hundreds of copies at once, each opening its own connection — and run the database out of connections. The fixes are a connection pooler or a database with a serverless-friendly driver. (Postgres Connection Pooling Explained.)

Unpredictable bills

Pay-per-use cuts both ways. A traffic spike, a bot, or a runaway loop means a bigger bill, not a slower site. Set spending alerts. (How to Stop Bots From Running Up Your AI App's Bill.)

No WebSockets, usually

Long-lived connections for real-time features (chat, live updates) don't fit the request-in, response-out model well. You'll typically need a separate service. (What Are WebSockets?.)

Serverless vs an always-on server

	Serverless	Always-on server / container
Idle cost	~Zero	Fixed monthly
Busy cost	Grows with every request	Fixed until you need a bigger server
Cold starts	Yes	No
Long-running jobs	Limited by timeouts	Fine
Background workers, WebSockets	Awkward	Natural
Local disk, in-memory state	Not reliable	Available
Database connections	Need pooling	Straightforward
Maintenance	Minimal	Depends on the platform

When to use which

Serverless is great for: APIs with spiky or low traffic, webhooks, scheduled tasks that finish quickly, and glue code between services.

An always-on server fits better for: apps with steady traffic, background workers, real-time features, long-running AI tasks, and anything that needs a persistent process or filesystem.

Many apps mix both. And "not serverless" doesn't mean managing a server yourself — managed platforms run always-on containers for you. (VPS vs PaaS.)

EasySpawn runs your app as an always-on process in a persistent workspace — no cold starts, no function timeouts, room for workers and WebSockets — on flat monthly pricing. See how it works or join the waitlist.