Next.js + Sanity: Monorepo with /studio folder vs separate frontend/studio repos?

Both approaches are totally valid, and the choice really comes down to your team's preferences and deployment strategy. There's no major technical disadvantage to either structure.

The /studio folder approach (embedded in Next.js) is what you'll see in most of Sanity's official examples and templates. Here's why it's popular:

• Simpler deployment: Everything deploys together as one Next.js app. Your Studio lives at yoursite.com/studio as a Next.js route
• Shared dependencies: You can share TypeScript types, validation logic, and other code between your frontend and Studio
• Monorepo benefits without the complexity: You get code sharing without needing to set up a full monorepo with workspaces
• Easier local development: One npm install, one dev server to run

The separate repos/folders approach works great too, especially when:

• Different teams manage each part: Your content team might have their own Studio deployment workflow
• You want Studio on Sanity's hosting: You can deploy Studio to yourproject.sanity.studio using the CLI's deploy command, completely separate from your frontend
• Multiple frontends: If you have iOS, Android, and web apps all consuming the same Sanity content, a separate Studio makes more sense
• You prefer strict separation of concerns: Some teams just like keeping things completely decoupled

My take: If you're a solo dev or small team building a single website, the embedded /studio approach is usually simpler. If you have multiple frontends or want your Studio completely independent, go with separate projects.

Both structures work identically from a functionality perspective - Sanity Studio is just a React app either way, and your Next.js frontend talks to Sanity's Content Lake via the same APIs regardless of where Studio lives. The Presentation Tool for visual editing works with either setup too.