How to host Sanity and Next.js together on Vercel: monorepo or single project?

2 replies
Last updated: Feb 23, 2021
I am new to the field. May I ask how should I host sanity and the nextjs web through vercel? Should I do it in monorepo or should I host it in one project? I have tried to host it in one project, however I am completely puzzled on how to do that as it seems there isn't a guide for it and when I read through many github projects that host both the web and sanity in the same project, the configuration method seems to differ from project to project. Thanks for any help!
AI Update

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:

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.

  1. Install next-sanity: npm i next-sanity
  2. 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} />
}
  1. Add your Studio URL to your project's CORS origins settings with authenticated requests enabled
  2. 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 thread
2 replies
Hi and welcome, Harry. I personally take the monorepo approach and I believe in most cases, Sanity does too. In fact, in this article Knut links to a list of monorepo pros and cons that you could consider.
To start off, you’ll need to have installed the CLI. If you haven’t already, run
npm i -g @sanity/cli
.
Here’s how I get set up. I create my project folder, then in it I add two folders:
sanity
and
web
. Call them what you wish. I go to the sanity folder and run
sanity init
, which creates a project. I usually choose the clean schema and then add in my own boilerplate, but you can choose whichever you think will best get you started. At this point, your Sanity project should be ready to go. You could run
sanity start
and start working in the Studio, but I would normally get the rest set up first.
In
web
you can set up however you choose. You’re planning to work with Next.js, so you can follow the steps (
create-next-app
or however you get started).
Once you’re set up, go to your project folder (containing
sanity
and
web
) and initialize your git repo. Make sure you have
.gitignore
files set up so you’re not committing node_modules and other ignorables. I’ll assume you’re deploying to GitHub but GitLab, BitBucket, or even a third-party repo should work, too.
I deploy all my studios to Sanity, which simply requires a
sanity deploy
command. Everything is committed to my GitHub repo but is accessible from
https://<name>.sanity.studio
.
For your front end, go to
vercel.com and choose New Project. Import the repo you created and committed to, and then when you get to the Import Project screen, select
web
(or whatever you called it). Vercel should automatically detect your framework and set your build settings.
If you run into any struggles, please post back here.
Thank you very much for your reply!

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.

Was this answer helpful?