Setting up Payload CMS: more hassle than Sanity, but a nice place to land
This blog is a twin. The same theme, the same content model and the same kind of static site as the Sanity test blog, but with Payload CMS behind it. The point was to compare the two honestly, from the perspective of someone who has spent years with PHP content systems. Here is what the Payload side taught us.
It is one app, and that changes everything
Sanity is a hosted content store with a separate editing app. You never run a server. Payload is the opposite: the admin panel, the API, the database access and the file uploads all live in one Node process that you host yourself. If you come from a PHP CMS this feels familiar, almost comforting. Your content is a SQLite file and a folder of images on a machine you control, and a backup is a copy.
The flip side is that every operational chore is yours too: the process manager, the memory, the migrations, the SSL, the restarts. With Sanity none of that existed.
Where the hassle was
Defining the content model and wiring up the site was quick and pleasant. Almost all of the friction was in getting the thing to run on a small production server.
- Memory. The default production build of the admin panel peaked at around 2.5 GB of RAM and was silently killed on a 2 GB server. Switching bundlers and capping the Node heap brought it down to about 1.4 GB. The running CMS itself is modest, roughly 350 MB, but the build is a real cost on shared hosting.
- Folder layout. Hosting tools assume the app lives at the root of the repository. Ours lived in a subfolder next to the site, so the generated start command pointed at the wrong place and the process crash-looped until we passed the folder explicitly.
- Zero-downtime deploys and state. Each deploy is a fresh clone, so the database file and the uploads have to live outside the release folder and be linked in. The first deploy failed simply because that shared folder did not exist yet.
- Migrations. In development the schema syncs itself. In production it does not, so every change to a collection means generating a migration file, committing it, and running it on deploy. Sensible, but one more thing to remember.
- Process manager details. The hosting default started several clustered instances. For a CMS with a single SQLite file, one process in plain fork mode is the right answer, and it took a manual fix to get there.
What was nice
- The content model is plain code. Collections, fields, access rules and hooks sit in a few TypeScript files, and the types for the whole API are generated from them.
- Drafts and versions come built in, with a clean rule that anonymous requests only ever see published documents.
- Images are resized on upload and served with their dimensions, so the static site can write proper
widthandheightattributes without a hosted image service. - The public site needed no framework at all. A short script fetches published posts from the REST API and writes HTML files. Publishing a post calls the host's deploy hook and the site rebuilds itself.
- An official MCP plugin exposes the collections to AI tools with the normal access rules. This post was drafted that way and published by a human.
Verdict so far
Sanity got us to a working blog faster, because the hard part was somebody else's server. Payload took an afternoon of hosting detours, most of them about memory and folder conventions rather than the CMS itself. Once up, though, it is the setup that is easier to explain: one app, one database file, one folder of images, and a plain static site in front. If you already run your own servers and like knowing where everything lives, that trade is a good one.
Boring choices, few dependencies, and a server you can read the logs on.