Get help on Discord

Best approach to structuring a repo for a studio and using separate repos for front end and studio.

5 replies
Last updated: Oct 5, 2021
hey everyone, i wanted to know what’s your best approach to structuring your repo for a studioI am redoing my portfolio site and i currently have the webView and the studio in the same repo but i feel like that’ll be an issue if i decide to redo my site
I would really like to know what approach you normally use when structuring monorepo or multiple
AI Update

Great question! This is something a lot of Sanity developers think about. There's no single "right" answer, but here's what the community generally does:

Two Main Approaches

1. Monorepo (Studio + Frontend Together)

This is actually pretty popular in the Sanity ecosystem. You'd have a structure like:

my-project/
  studio/
  web/

The main benefits are:

  • Easier to keep your content schema and frontend in sync
  • Simpler deployment setup (many hosting providers support multi-site monorepos)
  • Shared dependencies and tooling
  • Can run both dev servers with a single command

PNPM workspaces are a popular standard for this. You'd have a root package.json and pnpm-workspace.yaml that defines your apps. Tools like Turborepo can help with build orchestration too.

2. Separate Repos

This addresses your exact concern about redoing your site! Many developers prefer this because:

  • Clear separation of concerns - your Studio is independent from your frontend
  • Flexibility - you can completely rebuild your portfolio site (or build multiple sites) without touching the Studio repo
  • Simpler mental model - each repo has one job

Your Studio would be in one repo, and you'd just connect to it via the Content Lake from whatever frontend(s) you build. This is totally valid and some developers prefer this approach.

My Take

Given that you mentioned wanting to redo your site in the future, separate repos might be the better fit for you. Your content and content model live in the Studio repo, and any frontend just connects to your Sanity project via the API. This means you can:

  • Build a new Next.js site in a new repo
  • Keep your old site running while you build
  • Even have multiple sites using the same content

The Studio is really just your content editing interface and schema definition. Once it's set up, you don't change it that often, so keeping it separate from your frequently-changing frontend makes sense.

You can always move to a monorepo later if you find yourself constantly updating both together, but starting separate gives you maximum flexibility for your portfolio evolution.

Hi Obi. My sense is a lot of people use monorepos. For myself, up to this point, I just keep a separate repo for my studio and a separate repo for my front end. I know there are many advantages to monorepos that I may not be taking advantage of, but for my brain, I just like to keep everything separate. I have a vsc window open for each repo, with two terminal panes at the bottom (one where I do git and file operations and another running the local dev). It works for me, but I'm also curious to learn more about the advantages of a monorepo approach.
I'll add that I have two informal conventions that help. I keep both repos in a plain, non-version controlled directory, and I use a naming convention
my-project
  my-project-studio
  my-project-app
hey
user U
i was trying to mirror the gatsby template so i started with a monorepo but midway through the project creation i remembered the whole reason i’m on sanity is because i want to be able to switch to another frontend framework later on so i think i will switch to your seperate repo approachi think if i use your same folder suggestion i can still use lerna for both repos

Thank you
Hi Obi. If you haven’t seen it already, be sure to check out this post . It’s a few years old but still applies completely.
I like to structure my projects how Knut outlines in that post. The top-level folder is git-controlled, with separate subfolders for my front end and my studio. Each gets committed to git but when I build (to Netlify, Vercel, etc.) it considers only the front end folder. My studio gets deployed to Sanity with the 
sanity deploy
command. If I were to change out my front end framework, adding another folder would be no problem. Say I’m using Next.js. So in 
project/
I have 
next/
and 
studio/
. Now I want to switch my site to use SvelteKit, so I add another folder, 
svelte/
. I can work in 
svelte/
and source from Sanity, all while maintaining the code in 
next/
. When I’m ready to switch over, I just tell Netlify to build from 
svelte/
instead of 
next/
.
user A
thanksi thought i might have issues with the whole framework change but i guess the only issue is coming from the repo size which shouldn’t really be a problem
i think this is the approach i will be using in my next sanity project (i already converted and deployed with the split structure)
thanks a lot for the advice

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.

Get started for freeExplore the demo

Was this answer helpful?