Vercel Services: Run full stack on Vercel

To a user, an app with a Next.js frontend and a FastAPI backend feels like one product, and the same should be true for the engineers who build it. Instead, the two pieces are often deployed across different clouds with different development and deployment workflows.

Today we're introducing Vercel Services, which lets you run multiple frameworks in one Vercel Project. This unlocks:

• Atomic deployments: Your frontend, backend, and other services stay in sync and deploy or roll back together

• Shared preview deployments: See how any change affects all your services

• Internal service communication: Services can talk to each other without routing through the public Internet

Vercel handles the rest: routing, builds, deployments, and auto-scaling in production. The developer experience you already know from Vercel now covers your entire application.

Link to headingCompose applications with Vercel Services

Declare your services under the services key in vercel.json keeping the routing configuration explicit:

1
{
2
  "services": {
3
    "my_frontend": {
4
      "root": "frontend/",
5
      "framework": "nextjs"
6
    },
7
    "my_backend": {
8
      "root": "backend/",
9
      "entrypoint": "main:app"
10
    }
11
  },
12
  // my_backend has no public route
13
  // it is only reachable from my_frontend internally
14
  "rewrites": [
15
    { 
16
      "source": "/(.*)", 
17
      "destination": { "service": "my_frontend" }
18
    }
19
  ]
20
}

Services can be mounted to a shared routing table without the need for a reverse proxy or CORS.

The services configuration is recognized at multiple levels of the Vercel platform:

• The Deployments panel shows a visualization of services graph

• The Logs UI allows filtering by individual service

• The vercel dev CLI automatically runs all services giving you a production-like environment locally

Link to headingService bindings

Services can talk to other services internally, without routing through the public Internet. Here's an example how the new bindings configuration key enables that:

1
{
2
  "services": {
3
    "my_frontend": {
4
      "root": "frontend/",
5
      "framework": "nextjs",
6
      "bindings": [
7
        {
8
          "type": "service",
9
          "service": "my_backend",
10
          "format": "url",
11
          "env": "BACKEND_INTERNAL_URL"      
12
        }
13
      ]
14
    },
15
    "my_backend": { ... }
16
  },
17
  "rewrites": [ ... ]
18
}

Now the JavaScript frontend code can talk to the Python service internally via the URL stored in the BACKEND_INTERNAL_URL environment variable:

1
export async function GET() {
2
  const url = new URL("/users", process.env.BACKEND_INTERNAL_URL);
3
  const res = await fetch(url);
4
  const users = await res.json();
5
  return Response.json(users);
6
}

Service-to-service traffic stays on the Vercel network rather than egressing to the public internet. Many independent services can become one application connected by the same wiring, rather than separate deployments that you stitch together across hosts.

Link to headingFramework-defined infrastructure

Most frameworks run on Vercel with zero configuration. Framework-defined infrastructure means that each service's framework is auto-detected and auto-provisioned, from FastAPI and Flask for Python to Express and Hono for TypeScript, with first-class support for Go and Rust servers.

Services run on Fluid compute, autoscaling with traffic, while you pay only for active CPU time. But framework-defined optimizations go even deeper. With Django, for example, we automatically detect where static assets live and serve them from the CDN.

Link to headingThe full stack platform

Vercel Services gives Vercel a structured way to build and run your application.

Those services run on a platform that includes everything any backend could need, whether you're building APIs, agents, or background workers: compute, data, networking, background work, and secure connections to external services.

Link to headingIsolated compute for agent services

Agents can read files, run commands, and write code. But that capability needs to be secure. Vercel Sandbox gives each agent its own Linux computer: a filesystem, a shell, Docker support, and its own kernel, completely isolated from your deployments. Agents can execute code, grep files, and spin up Redis or Postgres as dependencies. Nothing inside the sandbox can touch your production environment.

With automatic persistence, state carries between sessions, and on Pro, sandboxes can run for up to 24 hours.

Link to headingReal-time backends with WebSocket support

Vercel Functions handle persistent WebSocket connections in every Vercel runtime, whether your backend is written in Node.js, Python, or Go. They work with standard WebSocket libraries like Socket.IO, and because connections run on Fluid compute with Active CPU pricing, you only pay for the time spent processing messages, not the time a connection sits idle.

Link to headingReach external services with Vercel Connect

Agents and backends need to reach services outside your project (Slack, GitHub, managed databases), which usually means storing a long-lived secret in your environment. Vercel Connect replaces that with a short-lived credential your app requests at runtime, scoped to the task in front of it. There is no long-lived secret left to leak.

Link to headingDatabases and storage for your services

You can provision a database from the Vercel Marketplace in a few clicks, with credentials injected for you, from providers like Neon, Supabase, and from AWS with Aurora PostgreSQL, Aurora DSQL, and DynamoDB. Amazon OpenSearch Serverless adds full-text and vector search, and Vercel Blob handles object storage. You can query and manage any of it without leaving Vercel, and both Blob and the AWS integrations authenticate with short-lived OIDC tokens rather than stored secrets.

Link to headingRun durable workflows and background jobs

Vercel Queues processes background jobs off the request path. Vercel Workflow handles durable multi-step processes that survive crashes and redeploys. And Vercel Cron runs work on a schedule. This is the part of a backend that outlives a request, and it runs on the same platform as everything else, so the long-running side of your backend needs no separate infrastructure.

Link to headingConnect privately and run on the right compute

When a backend needs to reach a private database or an internal network instead of a public service, Secure Compute, static IPs, and VPC peering open that path.

Functions run for up to 30 minutes on Pro and Enterprise, and Python backends deploy with up to 500mb of dependencies.

Underneath all of it, Fluid compute is the default for new projects, and Active CPU pricing bills for the time your code is actually running rather than the time it waits, the right shape for idle-heavy backend and AI work.

Link to headingA single platform for everything you ship

Vercel Services brings your frontend, backend, and supporting services into one project. They build together, preview together, deploy together, and communicate internally by default.

Combined with Vercel's built-in primitives for compute, data, queues, workflows, cron, secure networking, and sandboxed agent environments, you can run the full stack without stitching together separate platforms.

To start composing services, read the Vercel Services documentation and the routing and communication guide. If you are new to running a backend on Vercel, the zero-config backends post is the place to begin.