DrystoneCMS

Drystone CMS vs. Strapi
Same idea, far less installing.

Strapi proved that an open-source headless CMS with a decent admin could exist. The install grew along with it: Node, an external database, a build step for the admin, and an upgrade path that ships its own guide every major version.

Get started See the comparison

The short version

Strapi and Drystone want the same thing: self-hosted headless content with a usable admin. The difference is what you have to stand up and keep standing. Where Strapi is a Node project you build, deploy and migrate, Drystone is a single executable with the database inside it — and a schema that lives in git instead of in the database.

Point by point

Drystone CMS next to Strapi.

CriterionDrystone CMSStrapi
Install Drystone CMSDownload one binary and start it. Under a minute to a working admin. Strapinpx create-strapi-app, dependencies, database config, admin build.
Runtime Drystone CMSCompiled. No node_modules on the server, no build step at deploy time. StrapiNode with a full dependency tree, in production too.
Database Drystone CMSSQLite built in, in production as well. Postgres optional. StrapiSQLite in development; Postgres or MySQL in production, as a rule.
Content model Drystone CMSOne schema.yaml, plus a visual builder that edits that same file. StrapiThe Content-Type Builder writes schema files; in production the builder is closed.
Migrations Drystone CMSAutomatic and reversible, with a dry-run diff before they are applied. StrapiMoving schema changes between environments is a known sore point.
Upgrades Drystone CMSReplace the binary. API v1 keeps working for the whole 1.x line. StrapiMajor upgrades need codemods and hand-work on plugins and overrides.
Admin speed Drystone CMSFiltering and pagination happen in SQLite; usable past 100,000 documents. StrapiNoticeably slow on large collections and heavy relations.
Memory Drystone CMSAbout 181 MB idle — a €4/month VPS is enough. StrapiNode plus a database asks for a substantially bigger machine in practice.
Extensibility Drystone CMSWebhooks and the API. No plugin system, so no plugin breakage either. StrapiA real plugin system: more is possible, and more can break on upgrade.
Backup Drystone CMSCopy one file, plus the media folder. StrapiA database dump plus uploads, organised separately.

What Strapi does well

  • A mature open-source project with a large community and many ready-made integrations.
  • A genuine plugin architecture: you can customise the admin and the API deeply.
  • REST and GraphQL from the same definition, with fine-grained roles and permissions.
  • If you already run Node in production, it slots into what you maintain anyway.

Where it hurts in practice

  • The install is a project: dependencies, database, build step, deploy pipeline.
  • Major upgrades cost real work, especially with custom plugins or admin changes.
  • The admin slows down on large collections — exactly when you use it most.
  • Pushing schema changes to production is manual work with sharp edges.

Honest advice

When you are better off staying with Strapi.

Stay with Strapi if…

Choose Strapi if you need GraphQL, if you want to customise the admin deeply with your own plugins, or if your team already runs a Node deployment with a managed database that this fits into. That is a real situation, and Strapi is strong in it.

Choose Drystone if…

Choose Drystone if installation and upkeep are the costs you want to remove, and if your content model belongs in version control rather than in a database you have to sync between environments.

Switching

From Strapi to Drystone, in four steps.

  1. Move your Strapi content types to schema.yaml — collections, components and relations map almost one to one.
  2. Export your content as JSON and import it with the import CLI.
  3. Adjust your front-end queries: from /api/articles?populate=* to the same REST shape in Drystone.
  4. Repoint the webhook that triggers your static build, and switch Strapi off.

Install it now

Frequently asked

What people ask before switching.

Does Drystone support GraphQL?

Not in v1. There is standard REST with an auto-generated OpenAPI 3 spec, filtering, sorting, field selection and ?populate= for relations. GraphQL is on the roadmap as an optional layer — if you need it today, Strapi is the better choice on that point.

Can I extend the admin the way Strapi plugins do?

No, and that is deliberate: no plugin system in v1. You extend outside the CMS, through webhooks and the API. That costs flexibility and buys you an update that never breaks a plugin.

Does the admin slow down with a lot of content?

Filtering, sorting and pagination happen in SQLite rather than in the browser. Staying usable past 100,000 documents is an explicit non-functional requirement, not a side effect.

Other comparisons

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