Back to Sanity, from a PHP CMS mindset

For years my mental model of a website was simple: one server, a PHP application, a database next to it, and an admin panel that lived in the same codebase as the templates. Kirby, Craft, WordPress. Deploy meant uploading files. That model still works, and I still like it.

Sanity breaks that into three pieces, and understanding the split is most of the learning curve. The content store is a hosted service, the equivalent of the database and the uploads folder. The studio is the admin panel, but it is a standalone app that talks to the content store from the browser. The website is a third app, in my case Astro, which asks the content store for exactly the fields it needs.

What felt familiar

Defining a document type in the studio is the same job as registering a custom post type. A file describes the fields, the admin form appears. Astro templates are files with some code at the top and HTML below, which is closer to PHP templating than anything React-based I had tried before.

What felt foreign

The site does not get the whole post for free. Every field has to be asked for in a GROQ query. Publishing in the studio updates the content store instantly, but a static site only changes when it is rebuilt, so a webhook does the rebuild. And the studio has to be deployed separately when the schema changes, which is the part that took me longest to accept: the admin panel is just a bundle of files that can live anywhere.

This post was drafted from a terminal session through Sanity's MCP server, then reviewed and published in the studio. That workflow alone might be the thing that makes the switch worth it.