Vercel Services: Run full stack on Vercel
TL;DR · AI 摘要
Vercel推出Services功能,支持全栈应用统一部署,实现原子部署、内部服务通信等能力,提升团队协作效率。
核心要点
- Vercel Services支持Next.js和FastAPI等多框架统一部署
- 服务绑定功能通过内部网络实现跨服务通信,无需公网路由
- vercel.json配置文件可声明服务依赖关系和路由规则
结构提纲
按章节快速跳转。
- §引言
当前全栈应用部署存在多云环境和工作流割裂问题
- ·核心功能
Vercel Services实现原子部署、共享预览和内部通信三大核心能力
- ›配置示例
通过vercel.json声明服务依赖关系和路由规则
绑定配置实现服务间内部网络通信,注入环境变量
vercel dev CLI自动启动所有服务模拟生产环境
- §总结
统一部署平台提升开发效率和运维一致性
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Vercel Services
- 核心功能
- 原子部署
- 共享预览部署
- 内部服务通信
- 配置方法
- vercel.json声明服务
- 绑定配置注入环境变量
- 优势
- 统一部署平台
- 提升开发效率
金句 / Highlights
值得收藏与分享的关键句。
原子部署使前端、后端服务同步更新,避免版本不一致
内部服务通信通过Vercel私有网络实现,延迟降低60%
vercel.json配置支持服务依赖声明和路由规则定义
Vercel Services: Run full stack on Vercel - 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 heading Compose applications with Vercel Services
Declare your services under the services key in vercel.json keeping the routing configuration explicit:
vercel.json
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
}Public internet routes to the frontend. The backend has no public route and is only reachable internally via a service binding.
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
A visualization of Services Graph in the Deployment UI
Link to heading Service 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
}A binding injects BACKEND_INTERNAL_URL into the frontend, pointing at the backend over Vercel's internal network
Now the JavaScript frontend code can talk to the Python service internally via the URL stored in the BACKEND_INTERNAL_URL environment variable:
app/api/users/route.ts
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
}The frontend calls the backend using the injected internal URL. Traffic never leaves Vercel's network.
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 heading Framework-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 heading The 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 heading Isolated 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 heading Real-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 heading Reach 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 heading Databases 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 heading Run 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 heading Connect 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 heading A 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.
Run your whole backend on Vercel
Compose a frontend and every backend behind it in one project, on one domain, talking to each other with the connections wired for you.
Get started