Post
What it costs to fork the Sanity Studio
The editor at /admin is Sanity Studio v6 source, rebranded and pointed at our own API. Here is what that buys, what it costs, and how upgrades stay possible.

The Studio is the part of Sanity that is hardest to replace and easiest to underestimate. Field-level validation, the reference input with its live availability checks, Portable Text editing with block objects and annotations, the history timeline, presence, comments, the desk structure API — that is years of work, and a homegrown version of it is where content platforms go to die.
So this one is a fork of the real thing: Sanity Studio v6 source, imported with provenance recorded, rebranded, and configured to talk to our API instead of Content Lake.
What that costs, honestly
- A large browser bundle. The Studio is a full application;
/adminis a hard navigation for exactly that reason, so a visitor clicking a nav link is never handed it. - Upgrades are a merge, not a version bump. Every modification to the fork is recorded so the next upstream release can be replayed against a list rather than against a diff.
- Compatibility is a running obligation. The Studio boots against our API and calls endpoints we have to serve — including a few whose only job is to answer so nothing errors visibly.
What it buys
Everything an editor touches, working the way the documentation of the wider Sanity ecosystem says it works. @sanity/client connects unmodified. next-sanity connects unmodified. Schemas are ordinary defineType definitions, and the desk structure API is the real one.
The rule that keeps it maintainable
One rule, applied without exception: the fork is not where features go. Anything that can live in our own packages does — the auth provider, the API adapter, the asset plugin's serving side. The fork holds rebranding, the removal of hosted-service couplings that cannot work off Content Lake, and nothing else that can be avoided. Every one of those is written down, because the next upgrade has to be able to find them.
