Vercel Services: One Project, Multiple Frameworks
The frontend platform unifies frontends and backends in one project, with private internal communication and active usage pricing.
July 3, 2026 · 4 min read
TL;DR: Vercel Services allows deploying multiple frameworks in the same project, with private internal communication and active CPU billing. It simplifies full-stack development and reduces costs.
What happened?
Vercel has announced the launch of Vercel Services, a new feature that allows running multiple frontends and backends within a single Vercel project. According to the official Vercel blog, it is now possible to deploy full-stack applications with multiple frameworks on a shared domain, where services communicate privately with each other and deployments are built, previewed, and rolled back together. This feature represents a significant shift from the previous model, where each frontend or backend required a separate project, complicating dependency management and deployment coordination. With Vercel Services, the platform unifies these elements into one project, simplifying the workflow and reducing operational friction.
Technical details
Services are defined in the vercel.json file. Once defined, they appear in the dashboard and the Vercel CLI. Communication between services is done via the new bindings key, which allows the frontend to access the backend through an internal URL (BACKEND_INTERNAL_URL), without routing over the public internet. This improves security and reduces latency. Additionally, the deployment dashboard now visualizes a service graph, and logs can be filtered by individual service, making debugging easier. The CLI is also updated: vercel dev runs all services locally in a production-like environment.
Most frameworks work with zero configuration. Vercel automatically detects the framework of each service and provisions it, from FastAPI and Flask to Express and Hono, with first-class support for Go and Rust. Services run on Fluid Compute with Active CPU pricing, so you only pay for the time your code is actually executing. This contrasts with the traditional always-on instance model, which incurs fixed costs even during idle periods. Fluid Compute scales to zero when there is no traffic, which can significantly reduce costs for applications with intermittent usage patterns, such as sporadically used APIs or sites with variable traffic.
Why is it important?
Vercel Services unifies the workflow for teams using different technologies in the same project. Previously, to have a Next.js frontend and a FastAPI backend, you needed to create separate projects or use ad-hoc solutions like reverse proxies or manual network configurations. Now, everything resides in a single project, with coordinated deployments and secure internal communication. This simplifies management, reduces operational complexity, and accelerates development. For example, a team can simultaneously work on a React frontend and a Go backend, and changes are deployed atomically, avoiding version incompatibilities.
Moreover, the Active CPU pricing model is more efficient than always-on instances, which can reduce costs for applications with variable traffic. According to Vercel, Fluid Compute allows services to run only when there are active requests, which is ideal for backends that do not require 24/7 availability. This represents a competitive advantage over platforms that charge for fixed runtime, such as Heroku or AWS Elastic Beanstalk.
Market implications
This move positions Vercel more directly as a competitor to platforms like Netlify, Railway, or Fly.io, which already offer multi-service deployments. However, native integration with the Vercel ecosystem (Next.js, Turbopack, Edge Functions) and ease of use may attract developers seeking a unified experience. Unlike Netlify, which requires more manual configurations for backends, Vercel Services offers auto-detection of frameworks and automatic bindings, reducing the learning curve. Railway also offers multi-service deployments, but its pricing model is per container, while Vercel charges by active CPU time, which can be more economical for variable workloads.
For businesses, this means less friction when adopting microservices or full-stack architectures with a single provider. Teams can combine, for example, a React frontend with a Go backend, all managed from the same dashboard with atomic deployments. This could accelerate the adoption of microservices-based architectures, especially in startups looking to reduce operational complexity. Additionally, the ability to preview changes in a unified preview environment (with all services coordinated) improves collaboration between frontend and backend developers.
What readers should know
Vercel Services is available from the announcement. To get started, simply define the services in vercel.json and deploy. The official documentation provides detailed guides, including configuration examples for different framework combinations. It is important to note that while most frameworks are auto-detected, there may be edge cases requiring manual configuration, such as unlisted frameworks or custom build setups. Additionally, using internal bindings is key to security and efficiency; it is recommended not to expose internal URLs externally.
In summary, Vercel Services is a significant step toward a more integrated full-stack development platform, promising to simplify developer work and reduce operational costs. However, teams should evaluate whether their current stack is compatible and whether the Active CPU pricing model fits their traffic patterns. For applications with constant traffic, other solutions like dedicated instances might be more predictable in cost. Nevertheless, for most modern use cases, this feature represents a substantial improvement in the development and deployment experience.