CairnCMS is a self-hosted, open-source CMS and data platform for any SQL database.
Use CairnCMS to model your data, manage content, expose APIs, and automate workflows from one admin built on standard SQL tables you control.
What Teams Can Do with CairnCMS
CairnCMS brings data modeling, content operations, permissions, automation, dashboards, and file management into one no-code admin without moving your data into a proprietary layer.
A no-code studio for shaping and managing your data.
Bring an existing schema or build one from scratch in the CairnCMS studio. Define collections, fields, and relationships through the UI, or point CairnCMS at an existing database and let it reflect the schema that is already there. Either way, your data lives in standard SQL tables you fully control.
Explore data modeling
A content workspace built for every role.
Give teams an interface matched to the work they need to do. Collections, fields, and actions are scoped by permissions, so editors and other users can create and manage records, comment and @mention teammates, review revision history, and generate share links without being exposed to the underlying schema.
Tour the workspace
Granular permissions and access control.
Define unlimited custom roles with field-level permissions, conditional access rules, separate app and admin access controls, IP allowlists, and enforced two-factor authentication where needed.
Configure permissions
Automation without external tooling.
Build workflows directly inside CairnCMS. Trigger them from data events, incoming webhooks, cron schedules, or manual runs, then combine CRUD actions, conditional logic, email delivery, scripts, and external API calls. Each run is logged for inspection and debugging.
Build a flow
Real-time dashboards and insights.
Build no-code dashboards inside CairnCMS with metrics, time-series charts, tables, and rich text panels. Work from live data already in the system and control access through the same roles and permissions used across the admin.
Build a dashboard
A file library that fits your storage.
Manage images and other assets in a built-in file library with folders, metadata, and image transformations. Keep the same workflow whether files live on local disk, S3, Google Cloud Storage, Azure Blob, or Cloudinary, and switch storage backends through configuration instead of rewriting the app.
Manage files
Launch Faster with CairnCMS
CairnCMS gives teams the APIs, webhooks, extensibility, identity integrations, and revision history that teams need alongside the core admin.
REST and GraphQL APIs
Every collection gets REST and GraphQL endpoints automatically with field selection, nested filtering, relational traversal, sorting, pagination, and aggregation.
Multi-database support
Choose PostgreSQL, MySQL, MariaDB, or SQLite and keep the same admin experience, generated APIs, and automation layer.
Webhooks
Trigger outgoing HTTP requests on data events to integrate with downstream systems. Receive incoming webhooks through the flow trigger for the inbound side.
Extensions
Build custom interfaces, layouts, displays, modules, panels, hooks, endpoints, operations, themes, migrations, and Liquid email templates.
Schema-as-code
Snapshot collections, fields, and relations to a versioned file. Apply across environments via API or CLI with previewable diffs.
Config-as-code
Snapshot roles and permissions to versioned files. Apply across environments via API or CLI with previewable diffs.
SSO and identity providers
OAuth 2.0, OpenID Connect, SAML, and LDAP out of the box. Bring your own identity provider and let CairnCMS sit behind it.
Activity log
Track every create, update, and delete action in a system-wide log, with filtering by action, user, collection, and time.
A Project Named for What it Aims to Be
A cairn /kɛrn/ marks a route with something durable that no single person owns, and that anyone can find. CairnCMS was named for that idea.
- 1 Join GitHub discussions to share ideas
- 2 Open issues for bugs or feature requests
- 3 Improve the docs to help others adopt
- 4 Contribute code once the approach is clear
Commitments to the CairnCMS Community
These are the principles that CairnCMS returns to when evaluating features, roadmap decisions, and governance choices.
Keep the core small, and extend at the edges.
Core features should solve common platform needs. Specialized needs belong in extensions, even when they matter to many users.
Govern transparently.
Document major decisions in public with rationale. Roadmap changes, deprecations, breaking changes, and project policy should be explained, not just announced.
Choose usefulness over novelty.
CairnCMS should prioritize features that solve recurring operational problems over features that merely look advanced.
Prefer depth over sprawl.
When choosing between surface area and improving what exists, CairnCMS should favor consistency, polish, and maintainability.
Respect the operator's environment.
CairnCMS should respect that users control their deployment, data, schema, and infrastructure. It should avoid unnecessary assumptions and fit into existing environments whenever practical.
Frequently Asked Questions
Common questions about CairnCMS.
Why was CairnCMS created?
CairnCMS is a fork of Directus v10. It was created to preserve the earlier database-first platform under a fully open-source GPLv3 license.
Why should I use CairnCMS instead of Directus?
Use CairnCMS if you want the earlier Directus v10 platform under GPLv3 without the registration requirements, telemetry, or feature gates imposed by modern Directus.
It is especially well-suited to self-hosted teams that need full control over their infrastructure, multi-tenant architectures that depend on custom permissions, and organizations with privacy or compliance requirements that rule out mandatory analytics collection.
Can I use CairnCMS for production systems?
Yes. CairnCMS is intended for production self-hosted deployments, including larger and more complex systems, not just prototypes or demos.
Whether it is the right fit depends on your requirements, operating model, and comfort running the stack yourself, but the project is not positioned as a temporary or limited-use tool.
What databases does CairnCMS support?
CairnCMS actively supports SQLite, PostgreSQL, MySQL, and MariaDB. These are the databases the project is designed and tested around, including PostgreSQL 10 and MySQL 5.x coverage in the main-branch blackbox test matrix.
CockroachDB, Microsoft SQL Server, and Oracle support still exists in code inherited from Directus v10, but they are no longer part of the automated test matrix. If you depend on one of those vendors, treat that support as best-effort and plan to validate it yourself.
Will CairnCMS be compatible with future Directus releases?
CairnCMS is broadly compatible with Directus v10 at the API level. Its REST and GraphQL endpoints, authentication flow, permissions model, and admin behavior are based on the v10 platform, so frontends and integrations built against Directus v10 should require little or no change in most cases.
Projects using the JavaScript SDK will need a small migration, because CairnCMS ships its own SDK package and client factory instead of reusing the Directus package unchanged.
Compatibility with Directus v11 and later is not a project goal. CairnCMS will selectively adopt useful fixes and improvements, but it will not track upstream feature parity. Over time, the two projects will continue to diverge by design.
Will my Directus v10 data work with CairnCMS?
Yes. CairnCMS uses the same database structure as Directus v10, with one intentional change: the public role is migrated from `null` to a nil UUID sentinel to fix a long-standing constraint problem.
A migration handles that transition automatically, and existing collections, items, users, roles, permissions, and configuration should otherwise carry over as-is.
How can I contribute to CairnCMS?
The best way to support CairnCMS is to use it, file issues when you find bugs, contribute fixes when you can, and share the project with people who might benefit from it.
Contributions go through the standard GitHub pull request workflow with the Developer Certificate of Origin sign-off requirement. The contributing guide has details. The AI policy explains the project’s expectations around AI-assisted contributions.
For larger changes, file an issue first to discuss the approach before investing significant time in implementation.