DrystoneCMS

Drystone CMS vs. Contentful
Your content, on your server.

Contentful is a polished product with excellent documentation and a reliable CDN. It is also a subscription: your content lives with them, your limits are their limits, and growth is a conversation with sales.

Get started See the comparison

The short version

If you want SaaS where nobody has to run a server, Contentful does that well. Just work out what it costs over three years — with growth that is rarely linear — and what happens when you want to leave. Drystone runs the same kind of workload on a machine you own, without quotas, with your content in ordinary SQL tables you can export yourself.

Point by point

Drystone CMS next to Contentful.

CriterionDrystone CMSContentful
Hosting Drystone CMSYour server, your domain, your network rules. ContentfulTheir cloud. Self-hosting is not an option.
Price Drystone CMSFree. You pay for the machine it runs on. ContentfulA subscription per plan, with a jump the moment you cross a limit.
Limits Drystone CMSNo quotas on documents, API calls, users or bandwidth. ContentfulPlan limits on records, API calls, locales, roles and environments.
Content model Drystone CMSschema.yaml in git, reviewable in a pull request. ContentfulModelled in the UI; getting it into version control means migration scripts.
Data ownership Drystone CMSA SQLite file on your disk; export to JSON or Markdown with one command. ContentfulExport through the API, in their format, within their rate limits.
Lock-in Drystone CMSNone. The data is yours and the format is open. ContentfulReal: model, assets and workflows live inside their platform.
Latency Drystone CMSNext to your front end, or built statically ahead of time. No network hop. ContentfulA fast CDN, but always an external call from their regions.
Availability Drystone CMSYour responsibility — and your control when something breaks. ContentfulTheir SLA. During an incident you can wait, and that is all.
Onboarding Drystone CMSStart the binary, open the admin, done. ContentfulSet up an account, a space, environments and roles.

What Contentful does well

  • A polished product: the API is predictable and the documentation is excellent.
  • A reliable global CDN without you having to configure anything.
  • Mature workflows, localisation and roles for large editorial teams.
  • No server to operate — for some organisations that is the entire argument.

Where it hurts in practice

  • The price scales with usage and team size, and jumps at plan boundaries.
  • Plan limits force design decisions that have nothing to do with your product.
  • The content model lives in their UI; getting it into git takes extra tooling.
  • Leaving means pulling content and assets out of their API and remodelling them.

Honest advice

When you are better off staying with Contentful.

Stay with Contentful if…

Choose Contentful if nobody in your organisation may or wants to run a server, if you have a global editorial team with demanding workflow requirements, or if procurement would rather sign a vendor with an SLA than accept a VPS. That is a legitimate choice, and Drystone does not try to compete with it.

Choose Drystone if…

Choose Drystone if your content has to stay yours, if plan limits and API quotas are in your way, or if the bill grows with traffic you are already paying for.

Switching

From Contentful to Drystone, in four steps.

  1. Pull your content types from the Content Management API and write them into schema.yaml.
  2. Export entries and assets with the Contentful CLI and import them with the import CLI.
  3. Replace the SDK calls in your front end with plain fetch calls to the delivery API.
  4. Run both in parallel through one publishing cycle, then cancel the subscription.

Install it now

Frequently asked

What people ask before switching.

Will it be as fast without their CDN?

In most setups yes, and often faster: if you build statically, the CMS is not in your visitor's request path at all. If you serve dynamically, ETag and Cache-Control carry the cache, and you can put your own CDN in front.

What if my server goes down?

Your admin is down — your published site is not, if it is built statically. That is the inverse risk profile of SaaS: you are responsible, and you can also act during an incident instead of watching a status page.

Can I work with multiple environments?

Yes, and more simply than you are used to: an environment is a data folder plus a schema from git. Staging is a second binary with a second data folder, not a plan feature.