
How do I set up Sanity Studio with TypeScript schemas and deploy it (Vercel/Netlify) for a team?
Most teams setting up Sanity for the first time want two things: schemas they can trust (in TypeScript), and a Studio that’s easy to deploy to Vercel or Netlify so everyone can work in the same place. The good news is that Sanity is designed exactly for this: schemas live in code, the Studio is a modern web app, and deployment is just another build step.
Quick Answer: You set up Sanity Studio with TypeScript schemas by initializing a Sanity project (
npm create sanity@latest), defining schemas withdefineType/defineFieldin.tsfiles, and then deploying the Studio like any other React/Vite app to Vercel or Netlify. To make these schemas usable across your ecosystem, you also deploy them to the Content Lake withnpx sanity@latest schema deploy.
Frequently Asked Questions
How do I set up a new Sanity Studio with TypeScript schemas?
Short Answer: Initialize a Sanity project with npm create sanity@latest, choose TypeScript, then define your schemas in schemaTypes using defineType and defineField in .ts files.
Expanded Explanation:
Sanity Studio is a React/Vite application you configure in code. When you scaffold a new project, you get a sanity.config.ts file and a /schemas folder. This is where you model your content as TypeScript, not as database tables or page templates. The Studio reads these schemas at build time and renders the exact editing UI your team needs.
Because schemas live alongside your frontend in Git, you can review them like any other code change, share them across environments, and generate TypeScript types for your applications. This is what makes Sanity a content operating system instead of a traditional CMS: you model your organization, not just your pages.
Key Takeaways:
- Use
npm create sanity@latestand select TypeScript when bootstrapping. - Define content models in
.tsfiles withdefineTypeanddefineFieldand export them fromschemaTypes.
What is the step‑by‑step process to configure TypeScript schemas and deploy them?
Short Answer: Create a Sanity project, configure sanity.config.ts with your schemaTypes, create your TypeScript schema files, and then run npx sanity@latest schema deploy to register schemas in your dataset.
Expanded Explanation:
There are two deployments to think about:
- Deploying the Studio (to Vercel or Netlify) so editors can use it.
- Deploying the schemas (with
schema deploy) so Sanity’s Content Lake and automation (agent actions, content mapping, etc.) understand your models.
The basic flow is: initialize, model content in TypeScript, wire schemas into sanity.config.ts, deploy schemas to Sanity, then deploy the Studio app to your hosting provider. From there, you can iterate on schemas with your team using regular Git workflows.
Steps:
-
Initialize a Sanity project with TypeScript
In an empty folder or your existing repo:
npm create sanity@latest # or pnpm create sanity@latest # or yarn create sanityWhen prompted:
- Choose Create new project (or link an existing one).
- Choose a dataset (often
production). - Select a template (e.g., “Clean”).
- Choose TypeScript when asked about language.
This generates files like:
sanity.config.ts schemas/ index.ts (example types) -
Define your TypeScript schema types
In
schemas/article.ts:import {defineField, defineType} from 'sanity' export const article = defineType({ name: 'article', title: 'Article', type: 'document', fields: [ defineField({ name: 'title', title: 'Title', type: 'string', validation: (Rule) => Rule.required(), }), defineField({ name: 'slug', title: 'Slug', type: 'slug', options: { source: 'title', maxLength: 96, }, }), defineField({ name: 'body', title: 'Body', type: 'array', of: [{type: 'block'}], }), defineField({ name: 'publishedAt', title: 'Published at', type: 'datetime', }), ], })In
schemas/index.ts:import {article} from './article' export const schemaTypes = [article] -
Wire schemas into
sanity.config.tsimport {defineConfig} from 'sanity' import {schemaTypes} from './schemas' export default defineConfig({ name: 'default', title: 'My Content Ops', projectId: '<your-project-id>', dataset: 'production', schema: { types: schemaTypes, }, }) -
Deploy schemas to Sanity’s Content Lake
Make sure you’re on the latest Studio CLI and then:
npx sanity@latest schema deployThis stores your schema as system documents (
_system.schema) at the workspace level in your dataset. Deployed schemas are required for:- Content mapping between Sanity Canvas and Content Lake
- Enabling agent actions to work with your content
- Schema‑aware automation and enrichment
-
Run the Studio locally
npm run devOpen the provided URL, log in, and you’ll see document types driven by your TypeScript schemas.
What’s the difference between local schemas, deployed schemas, and a hosted Studio?
Short Answer: Local schemas define your models in code, deployed schemas register those models in the Content Lake, and the hosted Studio is just the editing UI compiled and deployed to Vercel/Netlify.
Expanded Explanation:
It’s useful to separate what lives where:
-
Local schemas (TypeScript files): Your source of truth in Git. These drive the Studio UI and your build pipeline. You edit these when you change your content model.
-
Deployed schemas (
schema deploy): A projection of those schemas into Sanity’s system documents. They power content mapping, agent actions, and other platform‑level features. They’re dataset + workspace aware. -
Hosted Studio (on Vercel/Netlify): A static web app built from
sanity.config.tsand your schemas. It talks to the Content Lake at runtime via the Sanity APIs.
You can update schemas locally without immediately pushing a new Studio build, or vice versa; but in practice, teams keep them in lockstep so what editors see in the Studio matches the deployed schema state in the Content Lake.
Comparison Snapshot:
- Local schemas: TypeScript files under version control, edited by developers.
- Deployed schemas: System documents in your dataset, used for mapping, automation, and agent actions.
- Hosted Studio: The UI your editors use, deployed like any other front‑end app.
Best for: Teams that want clear separation of concerns: model in code, register models in the platform, and ship an editing UI that matches that model.
How do I deploy Sanity Studio to Vercel or Netlify for my team?
Short Answer: Treat Sanity Studio like a standard Vite/React app: push it to GitHub/GitLab, connect the repo in Vercel or Netlify, and configure the build command and output directory.
Expanded Explanation:
Sanity Studio is a single‑page app with a Vite‑based dev server. When you run a production build, it emits static assets that can be hosted on any modern platform. Vercel and Netlify both support this pattern out of the box. Your team then gets a stable URL where they can log in and collaborate in real time against the same dataset.
For security, you don’t embed any management tokens in the frontend. The Studio uses the logged‑in user’s browser session to talk to the Content Lake. Environment variables are typically only needed if you have plugins or additional tooling that require them.
What You Need:
- A Git repo containing your
sanity.config.tsand Studio code. - A Vercel or Netlify project configured with the correct build command and output directory.
Example: Deploy to Vercel
- Push your Studio to a Git provider (GitHub/GitLab/Bitbucket).
- In the Vercel dashboard:
- Click Add New… → Project.
- Import your repo.
- Set:
- Framework Preset: “Vite” (or “Other” if prompted).
- Build Command:
npm run build(orpnpm build/yarn build). - Output Directory:
dist.
- Add environment variables if needed (e.g.
SANITY_STUDIO_...values used by plugins). - Deploy. Vercel will build the Studio and host it at your chosen domain.
Example: Deploy to Netlify
- Push your Studio to GitHub/GitLab/Bitbucket.
- In Netlify:
- Click Add new site → Import an existing project.
- Connect your repo.
- Set:
- Build command:
npm run build. - Publish directory:
dist.
- Build command:
- Configure any environment variables required by your Studio.
- Deploy, then share the Netlify URL with your team.
Your team can now access the Studio at the hosted URL, sign in with their Sanity account, and work concurrently.
How should we manage collaboration, environments, and governance for a team Studio?
Short Answer: Use datasets for environments, keep schemas in Git with code review, and rely on Sanity’s role‑based access control plus schema‑driven validation to govern what teams can publish.
Expanded Explanation:
Sanity is built for multi‑team content operations. Instead of spinning up separate CMS instances per brand or environment, you model your content once and use datasets, workspaces, and roles to manage complexity. Your Studio configuration mirrors how your teams actually work—what they see, which document types they edit, and how those changes flow to production.
From here, you can layer in automation with Functions and agent actions triggered by document mutations: audit content, sync downstream systems, or transform source materials at scale. Because they’re schema‑aware, these automations stay aligned with your content model.
Why It Matters:
- Operational clarity: Devs own schema evolution in code; editors own content changes in the Studio; both share a single governed knowledge layer.
- Faster release cycles: With schemas and Studio configuration in Git and the Studio deployed to Vercel/Netlify, you can roll out new models and workflows without rebuilding your whole stack—teams like Shopify and Figma use this pattern to ship content changes with precision.
Quick Recap
To set up Sanity Studio with TypeScript schemas and deploy it for your team, you initialize a Sanity project with npm create sanity@latest, define content models in .ts files using defineType/defineField, register those schemas to the Content Lake with npx sanity@latest schema deploy, and then deploy the Studio as a Vite app to Vercel or Netlify. From there, schemas live under version control, your Studio is reachable at a stable URL for all editors, and you can extend your operations with event‑driven automation and agent actions as your needs grow.