# How Vercel Services run on Fluid compute **Author:** Ben Sabic --- The backends you define as services run as [Vercel Functions](https://vercel.com/docs/functions), and those functions use [Fluid compute](https://vercel.com/fluid) by default. That means each backend in a [Services](https://vercel.com/docs/services) project handles concurrent requests, scales with traffic, and reduces cold starts without you managing a server or choosing a compute model. In this guide, you'll learn what Fluid compute gives the backends in a Services project, why it suits I/O-bound and agentic workloads, how Active CPU pricing works, and how to tune compute for each service. ## What Fluid compute gives your services The core of Fluid compute is optimized concurrency: instead of giving each request its own isolated instance, a single instance handles several requests at once. That's where most of its benefits come from, and a few of them you get without any configuration: - **Dynamic scaling**: Vercel reuses idle capacity in existing instances before starting new ones, so a service stays responsive under load and quiet during lulls. - **Reduced cold starts**: Vercel pre-warms production deployments and optimizes bytecode, so requests are less likely to wait on a fresh instance. - **Error isolation**: An unhandled error in one request doesn't crash the other requests sharing the same instance. - **Region and zone failover**: If an availability zone goes down, Vercel fails over to another zone, then to the next closest region if needed. Because this applies per service, a project with several backends gets the same concurrency and scaling behavior for each one, whether it's a [Python API](https://vercel.com/docs/functions/runtimes/python), a [Node.js server](https://vercel.com/docs/functions/runtimes/node-js), or another supported runtime. ## Why this matters for I/O-bound and AI backends Fluid compute pays off most when a service spends much of its time waiting rather than computing. Backend work like querying a database, calling an external API, or fetching embeddings with an AI model is I/O-bound: the request spends most of its time idle while it waits for a response. With one request per instance, that idle time is wasted. With Fluid, the instance uses that time to make progress on other requests. The practical effect is that a single instance can serve many in-flight requests, so a service needs fewer total instances to handle the same load. For an AI backend that mostly waits on model responses, or an API that mostly waits on a database, that concurrency is the difference between provisioning for peak request count and provisioning for actual CPU work. ## How you pay for it: Active CPU pricing Fluid compute separates the cost of running your code from the cost of waiting on I/O. Vercel bills three things for a service backend: - **Active CPU**: Charged only while your code is actively running. When a request is waiting on I/O, CPU billing pauses. - **Provisioned memory**: Charged while requests are in flight on an instance, until the last one finishes. - **Invocations**: Charged per incoming request. Between requests, an instance is paused, and you pay nothing. This pricing is what makes concurrency worthwhile for I/O-bound services: you pay for the CPU a service actually uses, not for the time it spends waiting on a database or a model, and a single instance serving many waiting requests keeps both CPU and memory usage efficient. ## Real-time services and WebSockets Fluid compute also enables a backend service to keep [WebSocket connections](https://vercel.com/docs/functions/websockets) open, which is the basis for real-time features such as live cursors and presence. Your WebSocket server runs as a service, and clients open a persistent connection through its route prefix rather than sending one-off requests. Real-time services follow the same model as any function-backed service, where instances are shared between requests and paused between work. For that reason, keep a few things in mind when building your application: - Keep shared state in an external store such as [Redis](https://vercel.com/marketplace?search=Redis), not in instance memory, because any instance can handle a given connection and instances are paused between work. - Handle reconnects on the client side, since a connection can close when an instance is recycled or when a duration limit is reached. - Account for function duration limits when a connection must remain open for an extended period. For walkthroughs of this pattern, see the cursors and presence build guides linked below. ## Tuning compute per service Each service is configured like a standalone Vercel project, so you can size its compute independently. Maximum duration is set per service in `vercel.json`, while memory is set in the dashboard, because Fluid compute is enabled by default and manages memory for you. To cap how long a service's invocations can run, add a `functions` object to the service and map a glob pattern to a `maxDuration` in seconds: `{ "services": { "backend": { "root": "backend/", "entrypoint": "main:app", "functions": { "**/*.py": { "maxDuration": 60 } } } } }` The glob matches the functions you want to customize, relative to the service's `root`. For example, `api/*.js` matches one level (`api/hello.js`), while `api/**/*.ts` matches every level (`api/hello.ts` and `api/hello/world.ts`). Set `maxDuration` to an integer between `1` and your plan's maximum. With Fluid compute enabled, you can't set `memory` in `vercel.json`. Set the default memory and CPU size for your functions in the [Functions section](https://vercel.com/d?to=%2F%5Bteam%5D%2F%5Bproject%5D%2Fsettings%2Ffunctions) of your project dashboard instead. Because each service is configured independently, you can give a heavier backend a longer timeout without affecting the others. For the current defaults, plan-specific limits, and supported runtime versions, see the [Vercel Functions configuration docs](https://vercel.com/docs/functions/configuring-functions/duration), the [function memory settings](https://vercel.com/docs/functions/configuring-functions/memory), and the [service configuration reference](https://vercel.com/docs/services/config-reference), as these values vary by plan and continue to evolve. Two related capabilities are worth knowing about. You can run work after a response is sent, such as logging or analytics, with `waitUntil`, so it doesn't delay the request. And when a job needs to outlast function duration limits, such as an agent loop that runs for hours or longer, use [Vercel Workflows](https://vercel.com/docs/workflows), which let code pause, resume, and maintain state. ## Deploy an App with Vercel Services Learn how to build on Services with these two step-by-step guides. Both create a real-time, full-stack app by pairing a frontend with a WebSocket backend within a single Vercel project that deploys to one domain. ## Resources and next steps - Learn how [Fluid compute](https://vercel.com/docs/fluid-compute) works and how it compares to traditional serverless. - Read the [Vercel Functions](https://vercel.com/docs/functions) docs for runtimes, regions, memory, and duration settings. - Set up a multi-service project with [The Complete Guide to Vercel Services](https://vercel.com/kb/guide/vercel-services). --- [View full KB sitemap](/kb/sitemap.md)