Open Source CMS
The dashboard you demo a CMS on is the part you will think about least a year in; what actually matters is how cleanly your articles, structure, and media come back out when you redesign or migrate. Content outlives the platform that publishes it, and a system that treats every page as a blob of HTML gets painful the moment articles, authors, and products need shared fields and reuse. The open source options here store content in databases and formats you can export in full, run on hosting you choose, and separate what you wrote from how it is rendered - so the next move is a copy, not a rescue, and no per-seat price grows with your team.
Strapi
Model content visually and Strapi generates REST and GraphQL APIs with a self-hosted admin
Ghost
Open source publishing platform with built-in newsletters, memberships, and paid subscriptions
Payload
A Next.js native headless CMS that installs in your app folder with a TypeScript backend
Directus
Wraps any SQL database in instant REST and GraphQL APIs, a no-code admin app, and auth
GrapesJS
Free and open source web builder framework for creating HTML templates inside CMS and other apps
WordPress
Open source CMS for creating a self-hosted website, blog, or app with a plugin API
Wagtail
Open source Django CMS with flexible content modeling, integrated search, and headless delivery
TinyMCE
Open source JavaScript WYSIWYG rich text editor with React, Vue, and Angular integrations
Grav
Flat-file CMS for building and managing websites with zero installation
Our picks
The right CMS depends on what you are publishing, so these four cover very different jobs.
Publishing and newsletters: Ghost Ghost is built for people whose site is really a blog, newsletter, and membership program at once, handling articles, email distribution, and paid subscriptions without bolting on separate systems. It ships a Content API and a Handlebars theme layer, and runs self-hosted with the official CLI or as the managed Ghost(Pro) service. MIT licensed and maintained by a nonprofit foundation.
Headless content backend: Strapi When the front end is your own application, Strapi lets you design content types visually and then generates REST and GraphQL APIs for each one automatically. It includes granular roles, a media library, internationalization, and draft-and-publish, and runs on SQLite, PostgreSQL, MySQL, or MariaDB. The core is MIT and self-hosted, with optional managed hosting.
Structured editorial CMS: Wagtail Wagtail suits teams that want editor-friendly publishing and developer control in one system. Its StreamField model gives authors flexible but structured content, a Content API enables headless delivery, and it handles multi-site and multi-language setups while scaling to millions of pages. Built on Django and BSD-licensed.
Flat-file, no database: Grav Grav drops the database entirely, storing content as files so setup is close to unzipping an archive. It uses Twig templating, Markdown content, and YAML config, with a package manager for plugins and themes and an optional admin dashboard. A good fit for a fast site you want to keep simple and version like code.
Picking a CMS that fits your content, not just your homepage
Editors feel a weak content model every day, long after the launch theme stops mattering. A CMS that stores each page as one block of HTML is fine for a small brochure site, but it turns painful once articles, authors, products, and events need shared fields, taxonomies, and reuse. Look at how a system defines content types, relationships, revisions, scheduled publishing, and multilingual variants before you fall for a template. Wagtail, for instance, is built around structured content with its StreamField model, while a flat-file tool like Grav or Bludit keeps things deliberately simple by storing pages as files with no database at all.
Next, decide how pages should be delivered, because that choice shapes your whole stack. A traditional server-rendered CMS keeps routing, preview, forms, search, and caching in one place, which is simpler for an editorial site; Ghost, Joomla, and Drupal work this way. A headless or API-first CMS such as Strapi or Directus hands the front end to your own application and delivers content over REST or GraphQL, which frees developers but moves preview, image handling, and authentication into your code. Static generation is fast and cheap to host, but publishing latency and rebuild failures become editorial problems.
Finally, treat extensions and the exit as part of the architecture. Many CMS projects fail because business logic ends up buried in plugin settings, shortcodes, or page-builder blocks that are hard to test and harder to move. Check how upgrades behave when extensions touch the database, and confirm content can be exported with stable IDs, slugs, media references, and revision history intact. A clean exit matters most when the site succeeds and the archive gets large.
Related categories
Frequently asked questions
What is the difference between a traditional CMS and a headless one?+
A traditional CMS renders finished pages itself, keeping editing, templates, routing, preview, and caching in one place. Ghost, Joomla, and Drupal work this way, which suits editorial sites. A headless CMS stores content and serves it over an API, leaving the front end to your own application: Strapi and Payload generate REST and GraphQL endpoints from your models. Headless frees developers but means preview, forms, and navigation have to be rebuilt outside the CMS.
When does a flat-file CMS make more sense than a database-backed one?+
Flat-file systems store each page as a file instead of rows in a database, which removes a whole layer of setup, backup, and patching. Grav and Bludit stand up from little more than an unzipped archive, and Publii builds a static site on your desktop that you then upload. That fits small, mostly static sites you want to version like code; it fits less well when you need heavy querying, relationships, or thousands of interlinked entries.
Do I need a full CMS, or just a rich text editor?+
They solve different problems. TinyMCE and CKEditor are editor components you embed inside an application to give users WYSIWYG editing, and GrapesJS builds HTML templates. None of them manage pages, users, or storage on their own. A CMS handles the content model, roles, and delivery around that editing. If you already have an app and only need the writing surface, an editor is enough; if you need to run a site, you want a CMS.
Can a CMS work with a database I already have?+
Most CMSs create and own their own schema, so you adopt their structure. Directus is the exception here: you point it at a new or existing SQL database, such as PostgreSQL, MySQL, or SQLite, and it layers REST and GraphQL APIs, authentication, and an admin app on top without migrating your tables. That is useful when the data already exists and you want an editing interface and API over it rather than a fresh content store.
What should I check about editorial workflow and permissions?+
Look past the basic author and editor roles. A serious CMS supports draft states, review steps, scheduled publishing, revision history, and rollback, plus clear permissions over media, menus, and content types. Strapi and Wagtail offer granular roles and draft-and-publish, and Webiny adds approval and scheduling workflows. Editors should never need administrator access just to fix a typo, so test who can do what before you commit.
Do the open source licenses differ in ways that matter for a commercial site?+
They do. Ghost, Payload, and Concrete CMS are permissively licensed under MIT, so commercial use is straightforward. Others are open-core or source-available: Strapi's core is MIT but its Enterprise Edition is paid, and Directus uses the Monospace Sustainable Core License, which is free for smaller organizations but requires a commercial license for larger companies using advanced features. Read the terms before you build a business on a paid tier.
What should a CMS let me export so I am not locked in?+
Raw HTML alone is not enough. A useful export includes structured fields, stable IDs, slugs, publication dates, authors, taxonomies, media files with alt text, internal links, redirects, and the relationships between entries. Git-based tools like TinaCMS keep content as Markdown and JSON in your repository, so it is portable by definition. For database-backed systems, confirm that revisions and custom fields come out in a documented format, not just a screen dump.