DrystoneCMS

Drystone CMS vs. Payload
Code-first, without the build chain.

Payload gets the code-first part right: your content model is TypeScript, it lives in git, and your types come out of it for free. The price is the rest of the stack — Node, an external database, and a config that grows with your project.

Get started See the comparison

The short version

Payload and Drystone agree on the important question: the content model belongs in version control. They disagree on the form. Payload makes your CMS part of your application code, with all the power and all the maintenance that brings. Drystone keeps it a separate executable with a schema file beside it — less to configure, less to deploy.

Point by point

Drystone CMS next to Payload.

CriterionDrystone CMSPayload
Content model Drystone CMSDeclarative YAML, plus a visual builder that edits the same file. PayloadA TypeScript config: maximum flexibility, and code you maintain.
Install Drystone CMSOne binary. No build step, no node_modules on the server. PayloadA Node project with dependencies, a build step and a deploy pipeline.
Database Drystone CMSSQLite built in; Postgres optional. PayloadMongoDB or Postgres, run and operated separately.
Types Drystone CMSdrystone types > types.ts generates typings from the schema. PayloadTypes come straight from your config — this is where Payload is strongest.
Editor autonomy Drystone CMSAn editor can change the model in the visual builder. PayloadModel changes are code: always a developer and a deploy.
Extensibility Drystone CMSWebhooks and the API; the core stays as it is. PayloadHooks, access control and custom React fields — you can do nearly anything.
Memory Drystone CMSAbout 181 MB idle, database included. PayloadNode plus a database; a heavier machine in practice.
Updates Drystone CMSReplace the binary; migrations are automatic and reversible. PayloadUpgrade the package, rebuild, redeploy.

What Payload does well

  • The content model as TypeScript: reviewable, type-safe, no separate generation step.
  • Deeply customisable — hooks, custom fields and access rules down to the detail.
  • Fully self-hosted and open source, with no cloud requirement.
  • A natural fit for a Next.js team that wants the whole stack in one repository.

Where it hurts in practice

  • Node plus an external database remain an installation and maintenance project.
  • The config grows with your project and becomes something to maintain in itself.
  • Model changes are always a code change plus a deploy — editors are on the sidelines.
  • Deploying needs a build step; there is no artefact you simply copy.

Honest advice

When you are better off staying with Payload.

Stay with Payload if…

Choose Payload if you want one Next.js repository where CMS and front end live together, if you need deep hooks and custom admin fields, or if your team prefers to express everything in TypeScript. That is a strong model and Payload executes it well.

Choose Drystone if…

Choose Drystone if the CMS is allowed to be a separate, boring piece of infrastructure: one file that runs, a schema you review, and an editor who can change the model without a deploy.

Switching

From Payload to Drystone, in four steps.

  1. Translate your Payload collections into schema.yaml; fields and relations carry over almost literally.
  2. Export your documents from Mongo or Postgres to JSON and import them.
  3. Replace Local API or REST calls in your front end with the delivery API.
  4. Move what lived in hooks to webhooks — or to the service that was listening anyway.

Install it now

Frequently asked

What people ask before switching.

Why YAML instead of TypeScript for the schema?

Because a declarative file can be edited by two parties. The visual builder in the admin writes that same schema.yaml, so an editor can add a field without a deploy — and you review it as a diff in a pull request. With a TypeScript config the second half is not possible.

Do I still get TypeScript types?

Yes. drystone types > types.ts generates typings that match your content model exactly, so your front end stays type-safe. The difference is that the types come from the schema rather than the schema coming from the types.

Can I run the CMS in the same repository as my front end?

Certainly — the binary and schema.yaml can live in your repo. What does not happen is the CMS becoming part of your application bundle: it stays a separate process with its own data folder.

Other comparisons

Drystone vs. WordPress Drystone vs. Strapi Drystone vs. Contentful Drystone vs. Sanity Drystone vs. Directus Drystone vs. Ghost Drystone vs. PocketBase