How to host Sanity and Next.js together on Vercel: monorepo or single project?
Great question! This is a common point of confusion for newcomers. Let me break down your options and give you clear guidance.
The Two Main Approaches
You have two viable options for hosting Sanity Studio and your Next.js site on Vercel:
1. Embedded Studio (One Project) - Recommended for Most Cases
This approach embeds Sanity Studio directly into your Next.js application as a route. It's simpler to manage and is the modern, recommended approach.
How it works:
- Your Next.js app lives at the root (e.g.,
yoursite.com) - Sanity Studio is accessible at a route like
yoursite.com/studio - Everything deploys together as one Vercel project
Setting it up:
With the next-sanity toolkit, you can embed Studio in your Next.js App Router. The official documentation on embedding Sanity Studio provides detailed guidance.
- Install next-sanity:
npm i next-sanity - Create a route at
app/studio/[[...tool]]/page.tsx:
import { NextStudio } from 'next-sanity/studio'
import config from '../../../sanity.config'
export default function StudioPage() {
return <NextStudio config={config} />
}- Add your Studio URL to your project's CORS origins settings with authenticated requests enabled
- Deploy to Vercel as a single project
Why this approach is simpler:
- One deployment, one domain, one Vercel project
- No monorepo complexity
- Studio automatically uses your Next.js environment variables
- Easier to maintain and understand
2. Monorepo (Separate Projects)
This keeps Studio and your Next.js site as completely separate applications that share code in a monorepo structure.
When to use this:
- You want Studio on a subdomain (like
studio.yoursite.com) - Multiple teams working independently on Studio vs. the website
- You have multiple frontends consuming the same Sanity content
Setting it up:
Your folder structure would look like:
my-project/ ├── apps/ │ ├── web/ (Next.js site) │ └── studio/ (Sanity Studio) └── packages/ (shared code)
On Vercel, you'd create two separate projects and set the "Root Directory" in each project's settings to point to apps/web and apps/studio respectively.
Why Projects Look Different
You're absolutely right that projects vary! This is because:
- Studio v3 introduced new embedding capabilities that older projects don't use
- Some projects were created before the App Router existed
- Different architectural needs (separate Studio vs. embedded)
- Evolution of best practices over time
My Recommendation
Start with the embedded approach (option 1). It's simpler, requires less configuration, and is what Sanity's current documentation and tooling support best. The next-sanity package makes this straightforward, and you avoid all the monorepo complexity.
Only go with a monorepo if you have specific requirements like:
- Multiple frontends (web + mobile app)
- Separate deployment schedules for Studio and website
- Different teams managing different parts
The embedded approach is not only easier to set up but also easier to understand as you're learning, and you can always refactor to a monorepo later if your needs change.
Show original thread2 replies
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.