Choosing how to structure your application on Vercel

When you build for the web, you often have a frontend and one or more backends, sometimes written in different languages, and you need to decide how they map onto Vercel. That choice shapes how you deploy, how the parts communicate, and how many domains you manage.

In this guide, you'll learn the three common ways to structure an application on Vercel, what each one is good for, and how to weigh the tradeoffs so you can pick the right structure before you start building.

Most applications on Vercel fit one of three structures. On Vercel, a project is the application you deploy and attach a domain to, so the structures differ mainly in how many projects you use and what runs inside them:

• A single framework: One framework handles both your frontend and backend in one project, such as Next.js with API routes.
• One project with Services: A single project runs multiple frontends and backends as separate services on one shared domain.
• Separate projects in a monorepo: One repository backs several independent projects, each with its own domain.

Three questions usually decide which structure fits:

• How many domains? One shared domain, or a separate domain per application.
• Should the parts deploy and roll back together, or independently?
• Are you running one language and framework, or several?

The rest of this guide looks at each structure through those questions.

Use a single framework when it can serve both your frontend and backend. Frameworks such as Next.js, SvelteKit, and Nuxt let you build pages and API endpoints in the same codebase, which Vercel deploys as a single project on a single domain.

This is the structure with the least to manage, and you don't need Services for it. Your frontend and API run in the same framework, built in a single deployment, and call each other in-process, so there's no cross-origin request to configure and a single set of environment variables to maintain. Reach for one of the other two structures only when a single framework can't cover what you need, for example, when part of your backend has to run in another language.

Use Services when you want to run multiple frameworks or backends in a single project, all served from a single domain. Services let you combine a frontend with one or more backends, including those across different languages and runtimes, and deploy them as a single project.

Services fit two situations in particular. The first is a polyglot application, such as a JavaScript frontend paired with a Python backend. The second is an application with multiple backends, where several APIs each have their own dependencies and build step. In both cases, Vercel builds each service on its own but serves them all from one domain, merging their routes into a single table and routing each request by its path prefix.

Because the services share an origin, they can call each other via environment variables generated by Vercel for each service, with no CORS setup required, and client-side URLs continue to work across preview deployments and custom domains. The tradeoff is a shared lifecycle. The services in a project deploy together and roll back together, so you can't ship or revert one on its own. When that shared lifecycle is what you want, Services give you a polyglot, multi-backend application under a single domain without the overhead of running multiple projects.

Use separate projects when your applications should remain independent, each with its own domain and deploy and rollback cycle. One repository can host several Vercel projects, so you keep your code in one place while deploying each application separately.

This structure suits applications that are genuinely separate, such as a marketing site, a dashboard, and a public API that belong to different teams or are released on different schedules. Each project has its own domain, settings, and access controls, and you can deploy or roll back one without touching the others. Vercel can also skip building the projects a commit didn't affect, so a shared repository doesn't mean every project rebuilds on every push.

The tradeoff runs opposite to Services. Because each project is served from its own domain, calls between them are cross-origin and need CORS handling, and you have more than one project to configure, deploy, and monitor. Choose this structure when independence matters more than sharing a domain and a deploy.

The three structures trade off along the same few dimensions:

Start with the most contained structure that fits, and add separation only when you have a reason.

If a single framework can serve both your frontend and backend, use it. It has the least to manage, and you can split things out later if your needs change.

If you need more than one framework, language, or backend, decide how independent the pieces should be. When you want them on a single domain, deployed together, and able to call each other without CORS, use Services. When each application should own its domain and release on its own schedule, use separate projects in a monorepo.

Two things should guide the decision:

• The number of languages or backends you're running
• Whether the pieces should share a domain and deployment or remain independent.

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.

• Read the Services overview to see how to define services in vercel.json.
• See Services routing and communication for how routing and cross-service environment variables work.
• Learn how to deploy separate projects in a monorepo.