Why I pair almost every Astro build with Sanity

When a school or a foundation calls and asks for “something like WordPress but not WordPress”, what they usually mean is: a comfortable admin for the editors, a fast public site, and no plugin chaos. The combination I keep arriving at is Astro on the front + Sanity in the back.

This is the honest case for Sanity — what it does well, where it bites, and when I would still pick something else.

What Sanity actually is

Sanity is two things in one product:

1. A real-time content database — JSON documents, fully queryable, hosted by Sanity.
2. A configurable editor (Sanity Studio) — a React app you ship as part of your project, with schemas defined in code.

You write a TypeScript schema. Sanity Studio reads it and renders an editor. Your Astro site queries the API and renders pages. Each side stays in sync because the schema is the single source of truth.

What sells me on it, project after project

The editor is the best in this category. Sanity Studio looks and behaves like a real editorial tool — not a settings panel. Live preview, structured navigation, custom input components, undo with proper history. For a non-technical editor it feels closer to Notion than to WP-Admin, and that matters every day they use it.

Schemas in TypeScript. I write the data model once, in code, and both the editor and the front-end use the same types. No drift between “what the editor can do” and “what my site expects” — the most common bug source in CMS projects, eliminated by the tool.

Images that just work. The image pipeline is excellent. On-the-fly responsive variants, AVIF/WebP, automatic cropping with hotspots set by the editor. For a school gallery or a museum image library, this alone saves a week of integration work.

Multilingual without a plugin tax. Localised fields are a first-class concept. The school portal we built in EN + PL + UA reused one schema, one set of components, three language fields per text — and the editor never had to think about it.

Generous free tier. A small organisation with one or two editors and a few thousand documents stays comfortably inside the free tier. It is not a free-trial trap.

Where Sanity bites

A first project takes about a day to wire up. You learn schemas, GROQ (Sanity’s query language), the Studio config. Once you have done it once, it is fast forever. The first time, it is a day.

Pricing scales with API calls. For a typical content site this is a non-issue — static generation means the CMS gets hit at build time, not on every visit. For an app that queries the CMS on every page view, you need to think about it. (Astro plus ISR or build-time queries handles this neatly for the kind of sites I build.)

GROQ is not GraphQL. It is its own query language. It is small and learnable, but you will be reading the docs at first. If you are deeply invested in GraphQL tooling, this can feel like a step sideways.

Who Sanity is right for

• Schools, kindergartens, foundations. Editors are non-technical, content matters, and the admin getting in the way is a deal-breaker. Sanity is exceptional here.
• Marketing sites with serious editorial workflow. News, events, galleries, document libraries, multilingual — everything you would build in a CMS, done well.
• Studios and agencies serving the above. Your team can ship a schema in a morning and the client can publish in the afternoon.

When I do not pick Sanity

• The site is tiny and rarely changes. A 3-page agroturystyka with no editorial team — I would use Markdown files in the repo or Keystatic. Sanity is overkill.
• The client wants Git-based content with hard ownership. Keystatic, Markdown, anything Git-based. Sanity content lives in their cloud — exportable, but not in a folder on your laptop by default.
• The workflow is so specific that no off-the-shelf CMS fits. When the client has an approval chain, three editor roles, scheduled publishing windows and a custom legal review step, I build a small custom admin in Next.js. Sanity tries to be flexible enough for everything, but at the edge cases, bespoke wins.

How I deploy it

For a typical project:

1. Astro site generated statically, hosted at the edge (Cloudflare Pages, Netlify, Vercel — pick one).
2. Sanity Studio as part of the same monorepo, deployed to its own subdomain — studio.client-domain.tld.
3. A webhook from Sanity that triggers an Astro rebuild whenever an editor hits “Publish”.
4. Live preview for editors via Astro’s preview deploys plus Sanity’s draft mode.

The end result for the client: they publish, the site rebuilds in seconds, they see the change live. The end result for me: one stack, one schema, one set of types, no plugin hell.

The honest summary

Sanity is the CMS I reach for first because, across nine projects in a row, it has been the right answer for the editor’s experience, the front-end’s speed, and my future-me sanity. It is not the only good answer — but it is the answer I default to until the brief gives me a reason to deviate.

For a school, a foundation, or any organisation that publishes news, events, galleries and documents on a regular basis: Sanity plus Astro is the combination I bet on every time.