How do I set up Sanity Studio with TypeScript schemas and deploy it (Vercel/Netlify) for a team?

Most teams want Sanity Studio to feel like part of their system, not an isolated tool: schemas in TypeScript, versioned in Git, and deployed to Vercel or Netlify with role-based access for editors. This FAQ walks through how to set that up, from npm create sanity@latest to a fully deployed Studio with schema deployment.

Quick Answer: Initialize a new Sanity Studio with TypeScript (npm create sanity@latest), define your schemas in code, connect the Studio to your Sanity project, then deploy the Studio app to Vercel or Netlify. Finally, deploy your schemas with npx sanity@latest schema deploy so they’re available across Sanity (Studio, functions, agent actions, and more).

Frequently Asked Questions

How do I create a new Sanity Studio with TypeScript schemas?

Short Answer: Use npm create sanity@latest (or pnpm/yarn) and choose TypeScript when prompted; Sanity will scaffold a Studio with TypeScript schemas ready to customize.

Expanded Explanation:
Sanity treats schemas as code that lives alongside your Studio configuration. When you bootstrap a new project, you get a Vite-based React app with schemaTypes defined in TypeScript, plus all the wiring you need to connect to your Sanity project and Content Lake. This lets you version-control your content model, generate TypeScript types for it, and ship schema changes through the same review process as your application code.

You can run this Studio locally, iterate on schemas, and then deploy it to Vercel or Netlify like any other modern frontend app. The same configuration file (sanity.config.ts) defines your project ID, dataset, plugins, tools, and schema types.

Key Takeaways:

• Use npm create sanity@latest to scaffold a Studio with TypeScript.
• Your schemas live as TypeScript in the repo and are versioned with the rest of your code.

---

What’s the step‑by‑step process to set up Sanity Studio and deploy it to Vercel/Netlify?

Short Answer: Scaffold the Studio, connect it to a Sanity project, test locally, push to Git, and then deploy the repository to Vercel or Netlify; they will handle builds on each commit.

Expanded Explanation:
Think of Studio as a React/Vite app that happens to be your content operating console. The workflow is: initialize → configure → run locally → commit → deploy. On Vercel or Netlify you’ll configure your build and output settings, wire in environment variables for SANITY_STUDIO_PROJECT_ID and SANITY_STUDIO_DATASET, and set the base path where Studio should be served.

Once deployed, your team uses that URL as the canonical editing environment, while your frontend(s) and agents read from the Content Lake via API.

Steps:

1. Bootstrap the Studio

   npm create sanity@latest
   # or
   pnpm create sanity@latest
   # or
   yarn create sanity
   

   • Choose:
     • “Create new project”
     • “Clean project with schema examples” (or similar starter)
     • TypeScript
     • The dataset name you want (commonly production)

2. Configure sanity.config.ts Inspect and adjust:

   import {defineConfig} from 'sanity'
   import {structureTool} from 'sanity/structure'
   import {schemaTypes} from './schemaTypes'
   
   export default defineConfig({
     name: 'default',
     title: 'Content Studio',
     projectId: 'yourProjectId',
     dataset: 'production',
     plugins: [structureTool()],
     schema: {
       types: schemaTypes,
     },
   })
   

   • Replace yourProjectId and dataset if needed (or use env vars).

3. Run Studio locally

   npm run dev
   # Studio will be available at http://localhost:3333 by default
   

   • Log in, confirm you see your dataset, create a test document.

4. Connect to Git

   git init
   git add .
   git commit -m "Initialize Sanity Studio with TypeScript schemas"
   git remote add origin <your-repo-url>
   git push -u origin main
   

5. Deploy to Vercel

   • In Vercel:
     • Import your Git repo.
     • Framework preset: “Other” (Vite) or “Static site” depending on setup.
     • Build command: npm run build
     • Output directory: dist
   • Set environment variables:
     • SANITY_STUDIO_PROJECT_ID=yourProjectId
     • SANITY_STUDIO_DATASET=production
   • Update sanity.config.ts to read from env if you prefer:

     const projectId = process.env.SANITY_STUDIO_PROJECT_ID!
     const dataset = process.env.SANITY_STUDIO_DATASET!
     

   • Deploy; your Studio will be accessible on the generated URL.

6. Deploy to Netlify (alternative)

   • In Netlify:
     • New site from Git.
     • Build command: npm run build
     • Publish directory: dist
   • Add the same environment variables as above.
   • Deploy and test Studio on the Netlify URL.

---

What’s the difference between TypeScript schemas and JavaScript schemas in Sanity Studio?

Short Answer: JavaScript schemas work fine, but TypeScript schemas give you static types, editor autocomplete, and safer integration with frontends and agents.

Expanded Explanation:
Under the hood, both JS and TS schemas resolve to the same runtime shape: a bundle of schema types passed into defineConfig. The difference is with TypeScript you get compile‑time checking that your fields, references, and document shapes line up across Studio, queries, and client code. You can generate types from your schema and reuse them in Next.js, Remix, Node scripts, or agent functions, so your GROQ queries and document transformations stay type‑safe.

This matters as your model grows. With TypeScript, renaming a field or refactoring a union type propagates through your codebase via the TypeScript compiler, rather than as runtime surprises in production.

Comparison Snapshot:

• Option A: JavaScript schemas
  • Faster to read for non‑TS users.
  • No built‑in type checking across Studio and client code.
• Option B: TypeScript schemas
  • Type‑safe defineType/defineField patterns.
  • Autocomplete and refactor‑friendly across Studio, frontends, and agents.
• Best for: Teams who version schemas in Git, share types across apps, and care about long‑term maintainability.

---

How do I deploy my schemas so they’re available across Sanity (Canvas, agent actions, etc.)?

Short Answer: Run npx sanity@latest schema deploy from your Studio folder after updating schemas; Sanity will store them as system documents in your dataset.

Expanded Explanation:
Studio always uses the schemas in your repo at build/runtime, but other Sanity services—like content mapping, agent actions, and future automations—need a canonical view of your content model. Schema deployment publishes that model into your dataset as system documents of type _system.schema at the workspace level.

Before deploying schemas, update to the latest Studio, and use a deploy token with appropriate permissions. Once deployed, agent actions and other schema‑aware tooling can reason about your content reliably.

What You Need:

• Latest Studio version installed in your project.
• A deploy token with schema deployment permissions.

Command:

# From your Studio directory
npx sanity@latest schema deploy

This:

• Saves schemas as _system.schema documents in your dataset.
• Ensures each workspace has its own schema set.
• Enables:
  • Content mapping between Canvas and Content Lake.
  • Agent actions and other schema‑aware automation.

---

How should we structure Studio and deployment for a multi‑person team?

Short Answer: Treat Studio as shared infrastructure: keep it in a Git repo, use branches and PRs for schema changes, deploy auto‑matically to Vercel/Netlify on merge, and gate access via Sanity roles plus your hosting provider’s auth.

Expanded Explanation:
For teams, the Studio is your content operations console and should follow the same governance as your application code. That means code reviews for schema changes, preview environments on feature branches, and a single “main” Studio instance for production editing. Access control happens in two layers: Sanity’s role‑based permissions on the project/dataset, and optional SSO/protected routes on Vercel/Netlify for the Studio URL.

You can run multiple Studios (e.g. a “playground” workspace and a “production” workspace), all pointing at the same or different datasets, but they should all share schema definitions in code to avoid drift.

Why It Matters:

• Controlled change management: Schema changes affect every consumer (web, mobile, agents). PRs and reviews keep things safe.
• Editor autonomy, dev focus: A stable Studio URL with clear roles lets editors own content updates without waiting on engineering.

---

Quick Recap

You set up Sanity Studio with TypeScript schemas by scaffolding with npm create sanity@latest, configuring sanity.config.ts, and defining your content model in TypeScript. Once your Studio runs locally, you push it to Git and deploy the Vite app to Vercel or Netlify with npm run build → dist. To make your schemas available across the Sanity ecosystem, use npx sanity@latest schema deploy, which stores them as _system.schema documents and powers schema‑aware tooling like agent actions. For teams, wrap all of this in Git‑based workflows, role‑based access, and automated cloud deployments.

Next Step

Get Started