Use Vercel Services when one repo needs multiple backends

Confirmed: Vercel Services is now available for deploying multiple frontends and backends inside one Vercel project. The practical change is simple: a Next.js frontend, Python or Go backend, and other services can share one domain, one deployment lifecycle, and private service-to-service bindings. Treat it as a beta-era structure decision, not a drop-in replacement for every monorepo.

What changed

Vercel published Services on June 30, 2026. The feature lets a single project define multiple services in vercel.json, build each service separately, and expose public traffic through top-level rewrites. Services can stay internal unless a rewrite routes traffic to them.

The new bindings configuration lets one service call another through an injected internal URL. Vercel says this keeps service-to-service traffic on its network instead of routing through the public internet, while the dashboard, logs UI, and vercel dev understand the service graph.

Key takeaways

• Vercel Services targets polyglot apps and multi-backend projects that should deploy together.
• Each service can have its own root, framework, entrypoint, runtime, and bindings.
• Public routing stays top-level in vercel.json; build and runtime configuration moves into the relevant service.
• Services are available in beta on all Vercel plans, according to the KB.
• Internal bindings grant reachability, but app-level authorization still belongs in your code.

Availability and access

Vercel's knowledge base lists Services as beta on all plans. A project must have the framework set to Services and a services key in vercel.json; otherwise, Vercel falls back to normal framework detection.

Billing follows the compute resources each service uses. The KB says services run like Vercel Functions with Fluid compute, Active CPU pricing, service-request charges for internal calls over bindings, and Fast Origin Transfer for returned bytes. Check your plan limits before moving a high-traffic API.

Practical LinkLoot angle

This is useful when the deployment shape is the problem. A team with a frontend, a FastAPI backend, and a worker-style service can keep one preview URL and one rollback path instead of splitting everything into separate projects, domains, and CORS rules.

It is less compelling when parts of the app need independent release control. If your dashboard, public API, and marketing site belong to different teams or need separate domains, Vercel's own structure guide points toward separate projects in a monorepo.

For AI-heavy apps, Services also changes the checklist around agent backends. You can pair a web app with a private backend service, then evaluate Vercel Sandbox, Queues, Workflows, Cron, Connect, and database integrations as surrounding primitives. Use LinkLoot's AI workflow automation guide when deciding which parts should run as services, workflows, or external tools.

What to verify before you act

• Confirm your project can be switched to the Services framework without breaking existing build settings.
• Check whether your backends fit Vercel Function limits for memory, duration, dependency size, and runtime.
• Model the billing impact of internal service requests, Active CPU, and Fast Origin Transfer.
• Test service bindings in preview deployments and local vercel dev, including missing env vars and failed internal calls.
• Review authorization between services; private routing is not the same as request authentication.

Source check

Confirmed by: Vercel's official changelog states that Vercel Services is available, supports multiple frontends and backends in one project, uses vercel.json, and provides private service bindings. Vercel's launch blog gives the broader full-stack framing and examples.

Documentation context: Vercel's Services KB explains beta availability, routing, bindings, billing, local development, and troubleshooting. Vercel's structure guide compares single-framework projects, Services, and separate monorepo projects.

Independent signal: this run did not find a strong third-party technical writeup yet. LinkLoot is publishing this as confirmed vendor documentation with practical adoption caveats, not as independent performance validation.