The Studio

Customising the Studio

Custom input components, document actions and plugins work as they do in Sanity — and the one rule that keeps upgrades survivable.

The customisation surfaces are the real ones: components.input, components.field, document.actions, document.badges, plugins, and the structure builder.

ts
export default defineConfig({
  // …
  document: {
    actions: (previous, context) =>
      context.schemaType === 'siteSettings'
        ? previous.filter((action) => action.action !== 'delete')
        : previous,
  },
})

The rule

Customise through configuration, never by editing the fork. Every change inside packages/content-studio is a change the next upstream release has to be replayed against. Configuration lives in your own package, survives upgrades untouched, and is reviewable as ordinary code.

When something genuinely cannot be done from configuration, the fix is a recorded modification with a note explaining why — not a quiet edit.

What is deliberately absent

Anything that only makes sense against a hosted backend: scheduled publishing, releases, Canvas, the hosted media library, hosted SSO. Those are not disabled features waiting to be turned on; they are surfaces this platform does not implement, and the compatibility page lists them.