Documentation
Everything you need, and where Sanity’s own docs still apply
This platform speaks Sanity’s API, so where a subject is genuinely identical — GROQ’s syntax, Portable Text’s shape, the patch operations — these pages link to Sanity’s specification rather than paraphrasing it. Where the behaviour differs, they say so in their own words.
Browse by area
Ten sections, in reading order.
Getting started
What this platform is, how to deploy one in a click, how to run it on your own machine, and what is in the repository.
Content modelling
Schema types, the page-builder pattern, Portable Text, references and validation — the decisions that shape everything downstream.
The Studio
The editor at /admin: what the fork changes, how to shape the desk, how drafts and publishing work, and how preview is wired.
Content API
The Sanity-compatible HTTP surface: fetching, mutating, document actions, history and the real-time stream.
Querying
GROQ against Postgres: how queries are executed, what the perspectives mean, how search works and how to keep a query fast.
Assets
Uploading images and files, what an asset id means, which transform parameters are served, and how bytes are delivered.
Identity and access
Signing in, the four roles and what each may do, and the row-level security that enforces them a second time.
Frontend
Putting a Next.js site in front of the API: reading content, rendering Portable Text and images, caching, and previewing drafts.
Operations
The build pipeline, environment variables, database migrations, and the free-tier limits that are real.
Reference
The route table, the GROQ support matrix, the CLI, and the compatibility notes in full.
Before you start
Do I need a Sanity account?
No. Nothing in a deployment talks to sanity.io. The Studio is a fork running from your own deployment, and the API it talks to is your own. You need a Vercel account and a Supabase account, both of which the Deploy Button will provision for you.
Can I bring an existing Sanity project’s schema?
Usually yes, and that is the point of the compatibility work: schemas are ordinary defineType definitions and the Studio is the real one. Content migration is a separate job — an export from Content Lake is NDJSON, and importing it means writing the documents through the mutation API.
What does it cost to run?
On free tiers, nothing, with real limits: a Supabase project pauses after seven days of inactivity (a daily cron keeps it awake), Realtime is capped, and Vercel Hobby limits optimised images and forbids commercial use. The operations section documents each of those rather than hiding them.
Is the content model in these examples fixed?
No. The example schema — pages with a page builder, posts, authors, documentation articles and features — is one package in the repository, and replacing it with your own is expected. The platform packages know nothing about those types.