Guides / Concepts explained

What Is Serverless? Serverless Computing Explained Simply

Serverless means running code without managing servers, paying only when it runs. How serverless functions work, cold starts, limits and when it's a good fit.

Mythex Team · 2026-09-29 · 5 min read

Serverless is a way of running code where you don't set up or manage any servers yourself. You hand your code to a cloud provider, and it runs that code only when something triggers it — a web request, an uploaded file, a payment notification — then stops. You typically pay for the time your code is actually running, not for a machine sitting idle.

Why serverless matters when you build with AI

When you build an app with AI and look at hosting options or code, you'll run into "serverless functions," "edge functions" or "cloud functions." Many hosting platforms offer them, and some AI builders deploy backends this way. Understanding the model helps you with three practical questions:

• Cost. Will your app cost money while nobody's using it?
• Speed. Why is the first request after a quiet period slower?
• Limits. Why did a long task — generating a big report, processing a video — time out?

It also helps to know what serverless isn't: it isn't the absence of a backend. You still have server-side code; someone else just runs the machines. For the basics, see what a server is.

An everyday analogy

A traditional server is like owning a car. It's always there, ready to go instantly, but you pay for it — insurance, parking, upkeep — whether you drive it or not.

Serverless is like calling a taxi. You pay only for the trips you take, and if a hundred people need a ride at once, a hundred taxis come. But there can be a short wait for the car to arrive (a cold start), each trip has a maximum length, and the driver doesn't remember you from your last ride (functions are stateless).

How serverless functions work

In the most common form, called functions as a service:

1. You write a function — a small piece of code that handles one kind of event, such as "handle a POST to /api/bookings."
2. You deploy it. The provider stores it and wires it to a trigger: a URL, a schedule, a new file in storage, a message on a queue.
3. An event arrives. The provider starts a copy of your function (or reuses a warm one), runs it and returns the result.
4. It scales on its own. If a thousand requests arrive at once, the provider runs many copies in parallel, up to your account's limits.
5. It goes idle. When traffic stops, copies are shut down. With nothing running, you pay nothing for compute.

A tiny serverless function in JavaScript might look like this:

export default async function handler(request) {
  const { name } = await request.json();
  return Response.json({ message: `Hello, ${name}` });
}

There's no code to start a server, open a port or keep a process running. The platform handles all of that.

"Serverless" is also used more loosely for other managed services that scale automatically and bill per use — serverless databases, for example, which pause when idle.

Key terms

A worked example: a small booking site

A yoga studio's booking site gets a burst of visits every Sunday evening when the new schedule goes up, and very little the rest of the week.

• On an always-on server, the studio pays for a machine 24/7, sized for Sunday evening's peak, and mostly idle otherwise.
• With serverless functions, GET /api/classes and POST /api/bookings are functions. Sunday's rush spins up many copies automatically; on a quiet Tuesday morning, almost nothing runs and the bill is close to zero.

The trade-offs show up too. The first person to open the site on Tuesday morning might wait an extra moment for a cold start. The database has to handle many short-lived connections from many function copies, which may call for a connection pooler. And if the studio later wants a "generate everyone's annual attendance PDF" task, it may exceed the function's time limit and need to run elsewhere.

When serverless fits — and when it doesn't

Common misconceptions

• "Serverless means no backend." It means no servers to manage. You still write and secure backend code.
• "Serverless is always cheaper." Cheap at low volume, but per-request pricing can add up at high, steady volume.
• "Serverless scales infinitely." Platforms have concurrency limits, and your database may become the bottleneck long before the functions do.
• "Files saved in a function will be there next time." Local storage is temporary. Use a database or file storage.
• "Scale-to-zero is the same as serverless." Related but not identical. Some platforms run your app as an ordinary server that sleeps when idle and wakes on the next request — similar savings and a similar first-request delay, but without function-style time limits per request.

What to ask your AI builder

• "Will this backend run as serverless functions or as an always-on or sleeping server? What does that mean for cost?"
• "Are any tasks likely to take longer than the platform's time limit? If so, how should we handle them?"
• "Store everything that must persist in the database or file storage, not in memory or local files."
• "How should the database connections be managed if many copies run at once?"
• "What's the delay on the first request after the app has been idle?"

How Mythex hosts apps

Mythex doesn't describe its hosting as serverless functions. When you publish, your app runs as a normal web app or container that Mythex manages for you — there's no hosting to set up. It's scale-to-zero: published apps and their databases sleep when idle and wake on the next visit, a sleeping app spends nothing on compute, and extra machines start only when traffic is heavy (Pro allows up to 3 per service). The attached Postgres database also sleeps after 5 idle minutes and is billed for the time it was awake. So you get much of the "pay for what you use" benefit, with the same kind of first-request delay after a quiet period. See hosting limits in the docs, and our guides on web hosting and reducing hosting costs.