Most headless CMSes want you to build your data model inside their system. You define content types, they generate a database, and your content ends up locked in a format only they understand. Directus inverts that. It wraps a SQL database you already own — PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, Oracle, CockroachDB — and reflects its schema into a no-code Studio with instant REST and GraphQL APIs. Your database stays a standard SQL database. If you stop using Directus tomorrow, your data is still yours, in tables you can read.
That database-first philosophy is Directus's defining strength, and it is why organizations from Prusa to Copa Airlines to Rescue.org have built on it. With roughly 37,000 GitHub stars, a TypeScript and Vue codebase, and a steady 2026 release cadence (v12.2 shipped in July with a new editor engine), Directus is one of the most capable open-source backends available. It gives you an admin UI, role-based access control down to the field level, event-driven Flows automation, an embedded AI assistant, and a native MCP server for AI agents — all layered on top of your own database.
But there is a catch that no feature list tells you up front, and it is the reason this article exists. In 2026, Directus changed its license from the Business Source License 1.1 to the
Monospace Sustainable Core License (MSCL) 1.0, a source-available license derived from the Fair Core License. It remains free for organizations under $5M in annual revenue and 50 employees; beyond that threshold, or for advanced and enterprise features, a commercial license is required. If you are a sovereign operator who chose open source to avoid exactly this kind of surprise, the license is the single most important thing to understand before you deploy. This is a long, honest teardown of what Directus delivers, how the database-first model works, what the license actually permits and forbids, and precisely where your data lives.
1. What Directus Is
Directus is a backend-as-a-service and headless CMS platform that sits on top of an existing SQL database. You point it at a database — new or existing — and it introspects the schema: tables become "collections," columns become "fields," and relationships become links the Studio understands. From that reflection it generates a full management interface and two APIs (REST and GraphQL) that operate on the same data with zero additional configuration.
The project is developed by Directus, Inc. (historically Monospace, the name now embedded in the license), a company that has deliberately kept the core free for most users while charging larger organizations. The
directus/directus repository reports in the high-30-thousands of stars, with 4.9k forks and active commits through late 2026. The current major line is v12, following the v11 series that introduced collaborative editing and the AI assistant as native features.
Crucially, Directus does not create its own opaque storage. It is a lens over your database. That single design decision ripples through everything: no migration lock-in, no proprietary content format, and the ability to use Directus alongside raw SQL, your own scripts, or other tools that touch the same tables. For teams that already have a database and want to expose it safely and quickly, that is the whole pitch.
2. The Database-First Architecture
The architectural idea is simple to state and powerful in practice. Instead of Directus owning the schema, your database owns the schema, and Directus mirrors it. You create a
customers table in PostgreSQL; Directus shows a
customers collection with the right fields. You add a column; the Studio updates. You write a row via
psql; it appears in the Studio.
This is fundamentally different from code-first CMSes like Strapi (where you define content types that generate tables) or framework-embedded CMSes like Payload (where the CMS lives inside your Next.js app). Directus is schema-agnostic in the other direction: it adapts to the database you already have. For an organization with an existing data model, that means you can add an admin UI and APIs without restructuring anything, often in an afternoon.
The cost of this model is that Directus is only as good as the schema it reflects. A poorly designed database produces a poorly designed Studio. Directus gives you tools to customize the presentation — display templates, interfaces, validation rules — but it cannot fix a bad underlying model. The practical advice is to design the database first, treating Directus as the presentation and API layer rather than the source of truth.
3. Instant REST and GraphQL APIs
The headline feature is that both REST and GraphQL APIs are generated automatically from your schema. You do not choose one or configure both; you get both, simultaneously, from the same data. REST follows a predictable pattern (
/items/{collection}) suitable for simple clients and scripts, while GraphQL lives at
/graphql for clients that want to shape responses precisely and avoid over-fetching.
For a self-hoster, this is the moment Directus earns its keep. A dashboard you built in a weekend can talk to your database through a typed, authenticated API without you writing a backend. The APIs respect the same role-based permissions as the Studio, so a read-only role cannot write through the API any more than through the UI. That consistency between the visual and programmatic surfaces is what separates a real backend platform from a glorified admin panel.
4. The Studio and No-Code Management
The Studio is the no-code interface non-technical teammates use to work with data. It is a Vue.js single-page app that renders your collections and fields as forms, tables, and detail views, with configurable interfaces (text inputs, relation pickers, image uploaders, WYSIWYG editors) per field. Non-technical users get a clean, intuitive tool; engineers keep control of the underlying schema.
Directus also includes digital asset management: uploaded files are stored in a configured storage adapter (local disk or an S3-compatible bucket) and referenced from the database. That means your images and documents live wherever you point the storage driver — another point of data sovereignty, because the asset store is your choice, not Directus's.
5. Role-Based Access Control, Down to the Field
Permissions are where many open-source CMSes cut corners, and Directus does not. Its policy-based access control allows grants at the collection level and the field level, with conditions expressed as rules (for example, "a user can read items where
status equals
published, or where
author equals the current user"). The same policies apply whether a request comes from the Studio, the REST API, or the GraphQL API — and, importantly, whether the actor is a human or an AI agent connected via the MCP server.
For a sovereign operator, field-level RBAC is the difference between "anyone with an API key can read everything" and "the public API key can only read published rows, never the internal notes column." Directus makes the granular model the default rather than the enterprise add-on, which is unusual and worth emphasizing. The operational responsibility is to actually design those policies; the capability is there, but a lazy "admin role for everyone" configuration throws it away.
6. Flows: Event-Driven Automation
Flows are Directus's built-in automation engine, configured through the Studio rather than written as external cron jobs. A Flow triggers on a CRUD event (item created, updated, deleted), a schedule, or a webhook, and runs a sequence of operations: send an email, make an HTTP request, run custom JavaScript, transform data, call another Flow. For teams building internal tools, this replaces a fair amount of glue code that would otherwise live in a separate orchestration service.
The honest limitation is that Flows run inside the Directus process and are constrained by what the operation nodes expose. For complex pipelines you will still reach for a general workflow tool (n8n, covered in this series, is the natural companion) — but for the common "when a record changes, notify someone and update a related table" pattern, Flows keep the logic where the data lives. The two tools compose well: Directus as the data and API layer, n8n as the heavier automation layer when Flows get unwieldy.
7. The AI Assistant and Native MCP Server
Directus has leaned hard into AI in 2026, and this is where it becomes relevant to operators building agentic systems. The Studio embeds an AI assistant that can create, translate, and act on content directly. More architecturally significant is the
native MCP server: any MCP-compatible agent or tool — Claude, Cursor, ChatGPT, custom agents — can connect to your Directus instance and operate on live data under the same role-based permissions as a human user.
The governance model here is the part to pay attention to. Because the MCP server inherits Directus's access policies, an AI agent connected via MCP is not granted special powers; it operates as the role you assign it. That "governed by default" stance is the right one, and it means you can give an agent read access to published content without accidentally handing it the keys to unpublished drafts. The caveat is the flip side: if you assign the agent an over-broad role, the agent inherits that breadth. The permission system is your safety, and MCP does not bypass it — but it also does not save you from misconfiguration.
8. Collaborative Editing and Multi-User Work
Since v11.15, Directus supports native collaborative editing: multiple users can work in the Studio with presence and concurrent-editing behavior rather than last-write-wins clobbering. For content teams this removes a class of "I overwrote your change" incidents. It also supports granular user management, with the caveat that the user directory is Directus's own — it is not an external IdP by default, though Directus can be wired into external auth where needed.
This is a reasonable place to note the contrast with a pure database tool: Directus is not just an API generator, it is a multi-user application platform. The collaborative editing, roles, and notifications make it usable by non-engineers, which is the actual reason organizations adopt it over "just expose the database with a thin API."
9. Self-Hosting: The Moving Parts
A self-hosted Directu deployment is more than one container. At minimum you need the Directus API/server (Node.js), a database (one of the supported SQL engines), and a storage adapter for files (local or S3-compatible). For production you add Redis (caching and real-time), a queue for Flows and async work, and a reverse proxy with TLS in front (Caddy, covered in this series, is the natural choice for automatic HTTPS).
The database is the source of truth and must be backed up as such. Directus stores its own internal tables (collections metadata, roles, permissions, activity logs, presets) in the same database, prefixed so they do not collide with your data tables. That means a single database backup captures both your content and Directus's configuration — convenient for restore, but it also means Directus's tables are part of your schema and should not be hand-edited.
Resource cost is moderate: Node.js is heavier than a Go binary like Authelia (also in this series), and a busy instance benefits from real memory and a Redis cache. This is not a tiny edge tool; it is a platform, and it should be sized and operated like one.
10. The License: The Part Everyone Skips
This is the section that matters most for a sovereign operator, because Directus's license is not a standard open-source license, and it changed in 2026.
Historically, Directus was open source under a permissive license, then moved to the
Business Source License (BSL) 1.1 in 2023, with an additional use grant. In 2026, it moved again to the
Monospace Sustainable Core License (MSCL) 1.0, described as a source-available license derived from the Fair Core License. Under MSCL 1.0, Directus is free for most builders: organizations with under $5M in annual revenue and/or funding combined, and under 50 employees, can use Directus freely in any way, including commercially, with no license fee. Organizations above those thresholds, or using advanced/enterprise features, require a commercial license.
The practical implications are concrete. If you are an individual, a startup, a homelab, a small business, or a non-profit under the threshold, Directus is effectively free and you can use the source. If you are a larger enterprise running Directus in production with advanced features, you are expected to buy a commercial license. This is not a trap unique to Directus — it is the Fair Core License family's model, also seen in projects like MariaDB's MaxScale and (in spirit) in the BSL moves of several 2020s open-source companies. But it is a departure from the Apache/MIT/AGPL world most self-hosters assume, and it must be a conscious decision, not a surprise discovered at renewal time.
11. What "Source-Available" Actually Means for You
The MSCL is source-available, not open source in the OSI sense. You can read the source, and under the free tier you can run and modify it. What changes versus a true open-source license is the field-of-use and size restrictions, and the absence of the unrestricted commercial freedom that MIT or Apache grants. For a self-hoster under the threshold, the day-to-day experience is identical to open source: you clone, you deploy, you own your data. For an organization above the threshold, the obligation to obtain a commercial license is the difference.
There is also a strategic risk worth naming: license terms can change again. Directus moved BSL → MSCL in a single year. A future change could tighten terms further. For a sovereign operator whose entire data layer depends on Directus, that is a governance consideration — not a reason to avoid it, but a reason to keep your database portable (which the database-first model already does) so you are never held hostage by a license shift you cannot accept.
12. Directus vs the Rest of the Series
Positioning Directus against tools we have covered clarifies its niche.
Supabase (covered) is a backend platform built around Postgres with its own auth, realtime, and storage — more opinionated and more "backend-as-a-service," less of a no-code data Studio.
NocoDB (covered) is a spreadsheet-style view over SQL databases, lighter and more tabular, without Directus's API-first, RBAC-deep, app-platform posture.
Strapi and
Payload are code-first CMSes that generate the database rather than reflect it — the inverse of Directus's database-first approach.
The differentiator is the combination: database-first + instant dual APIs + field-level RBAC + no-code Studio + Flows + MCP, all in one. If you want to wrap an existing SQL database in a manageable, API-exposed, permissioned layer without writing a backend, Directus is one of the strongest options. If you want a spreadsheet feel, NocoDB is lighter; if you want a full Postgres-backed BaaS, Supabase is broader; if you want to define content types in code, Strapi or Payload fit better.
13. Real Costs of Running Directus
The direct costs are modest for small deployments: a Node.js host, a database you may already run, and storage for assets. There is no license fee under the threshold. The indirect costs are the usual platform tax — more moving parts than a single binary, a need for Redis in production, and the operational maturity to back up the database and manage upgrades.
The less obvious cost is the commercial license cliff. If your organization grows past $5M revenue or 50 employees while running Directus in production with advanced features, you must budget for a commercial license or restructure. For a homelab or a sub-threshold business, this is a non-issue; for a scale-up, it is a line item to plan for, not a surprise to absorb. The sovereign move is to know which side of the threshold you are on before you commit your data layer to it.
14. Where Your Data Goes
A sovereign operator's first question is always "where does my data physically live," and Directus answers cleanly. All structured data — your collections, your content, Directus's own metadata, roles, and permissions — lives in
your SQL database. You choose the engine and the host. Directus does not ship your data to a vendor. Uploaded files live in your configured storage adapter, local or S3-compatible, also under your control.
The outbound data flows are minimal and opt-in. Directus Cloud is an optional managed offering; self-hosting avoids it entirely. The AI assistant, if enabled, calls the model provider you configure (the assistant is not a mandatory phone-home). The MCP server only exposes what your role policies allow and only to agents you connect. There is no mandatory telemetry that removes your data from your infrastructure. In short: with self-hosting, your data stays in your database and your storage — exactly where a sovereign operator wants it.
15. The Limitations Worth Naming
Beyond the license, Directus has scope limits. It is not a general application framework — complex frontends are built by you in your own stack consuming the APIs, not inside Directus. Heavy automation may outgrow Flows and need an external orchestrator. The Studio is powerful but reflects your schema; a bad database design produces a bad Studio. Real-time collaboration and scaling need Redis and thoughtful configuration. And while the free tier is generous, the advanced/enterprise features gated behind commercial licensing mean that "everything is free" is only true below the threshold.
None of these are reasons to avoid Directus; they are the boundaries of a tool that does a specific job well. The one that deserves the most deliberate consideration is the license, because it is the one that can change your cost structure after you have already committed.
16. Upgrades and Version Discipline
Directus moves fast — v11 to v12 in roughly a year, with editor and AI features landing regularly. Fast movement means upgrade discipline matters. Major versions can change Studio behavior, config keys, and extension formats, so read the migration guide before jumping majors. Because your database holds both content and Directus metadata, back up the database before every upgrade; a failed migration is recoverable only if you have the pre-upgrade dump.
Extensions (custom endpoints, hooks, interfaces, modules) are built with Vue and Node and bundled in a specific format introduced in v11. If you write extensions, factor upgrade churn into their maintenance cost. The recommendation is to pin a major version in production, stage upgrades on a copy of the database, and only promote after verifying the Studio and critical Flows still behave.
17. A Deployment Sketch
A realistic small production layout: a reverse proxy (Caddy) terminating TLS and routing to the Directus container; the Directus container with
DATABASE_URL pointing at your managed Postgres; Redis for cache and realtime; an S3-compatible bucket for assets; and nightly database backups. The whole thing fits on a modest VPS if traffic is light. Scale adds replicas behind the proxy, a larger database, and Redis clustering as needed. The point is that the deployment shape is conventional and portable — nothing about it locks you to a specific cloud, and the database-first model means you could even front the same database with a different tool if you ever left Directus.
18. Who Should Run It, and Who Shouldn't
Directus is for teams that have (or want) a SQL database as the source of truth and need to expose it through a no-code Studio and authenticated APIs without building a backend. Homelabs, startups under the revenue threshold, internal tooling, and content platforms are the sweet spot. If you value data portability and field-level permissions and you are comfortable with the license terms, it is an excellent choice.
It is not for you if you need a true OSI open-source license with unrestricted commercial use regardless of size — choose a Postgres-native or Apache/MIT tool instead. It is not for you if you want a turnkey hosted product without operating Node, a database, and Redis. And it is not for you if your governance rules forbid source-available licenses outright; read the MSCL 1.0 text and get the answer before you deploy.
19. The Sovereignty Verdict
Weighing Directus for sovereignty produces a nuanced verdict. On data, it is excellent: your database is yours, your files are yours, and the database-first model means no lock-in at the storage layer. On license, it is a conscious trade: free and effectively open-source below the threshold, source-available with commercial obligation above it, and subject to future license change. For most self-hosters and small organizations, the practical experience is indistinguishable from open source and the data portability is genuine. For larger organizations, the license is a real cost and a real risk that must be budgeted and governed.
The sovereign operator's move is to exploit the data portability while respecting the license boundary: keep your schema clean, back up the database, and know your threshold status. Do that, and Directus gives you a powerful, self-owned backend without surrendering your data to a vendor — which is the entire point of self-hosting.
20. Schema Design Patterns for Database-First
Because Directus reflects your schema rather than generating it, schema design is the lever that determines whether the Studio is a joy or a liability. A few patterns pay off consistently. Use clear, singular collection names (
post,
author) rather than plural or acronym soup, because the Studio surfaces them verbatim. Define relationships with explicit foreign-key columns and let Directus model them as relational fields, including many-to-many through junction tables it detects automatically. Avoid storing large blobs in the database; keep files in the storage adapter and reference them by path. Use status enums (
draft,
published,
archived) rather than booleans where lifecycle matters, because your RBAC policies will key off those values. And resist the temptation to over-normalize for Directus's sake — the database is yours first, and Directus adapts. The teams that get the most from it design the database for the data, then shape the Studio presentation on top, rather than the reverse.
21. Security Model Deep Dive: Policies and the Public Role
Directus ships with a
public role that, by default, has no access — a sane starting point. Every other role is a set of permissions over collections and fields, optionally gated by filter rules. The powerful pattern is the conditional policy: a
guest role might read only
post rows where
status = published, while an
editor role reads and writes all posts but cannot delete, and an
admin role does everything. Field-level rules take this further — the public API key might see
title and
body but never
internal_notes or
author_email. Because the same policies govern Studio, REST, GraphQL, and MCP, there is one authorization surface to reason about, not four. The discipline required is to actually enumerate roles and not fall back to "everyone is admin because it's easier." The capability is there; the security is your responsibility.
22. Real-Time and Subscriptions
Beyond request/response APIs, Directus supports real-time via WebSockets — clients can subscribe to collection changes and receive updates as rows are created, updated, or deleted. This is what powers live dashboards and collaborative presence without polling. For a self-hoster, the practical note is that real-time benefits from Redis and a correctly configured WebSocket endpoint behind the proxy (Caddy or Traefik must forward the upgrade). The feature is genuinely useful for internal tools where multiple operators watch the same data, but it also widens the attack surface if the public role is granted subscribe access to sensitive collections. As with everything in Directus, the permission system is the control; leave the public role empty and grant real-time narrowly.
23. Extending Directus: Hooks, Endpoints, and Modules
Directus is extensible through a documented extension system.
Hooks are server-side event handlers that fire on data events — useful for enforcing invariants the schema cannot express, or syncing to an external system.
Custom API endpoints let you add business logic as first-class routes under the same auth and permission model.
Custom modules and interfaces extend the Studio UI with Vue components for domain-specific workflows. The extension format was restructured in v11 into a cleaner bundled layout, which means extensions written for older versions need migration. The trade to name is maintenance: every extension you write is code you own and must keep working across Directus upgrades. For most teams, the built-in Flows cover enough that custom extensions are the exception, not the rule — but when you need them, the model is clean and well-supported.
24. Migrating To and From Directus
The database-first model makes migration unusually sane in both directions. Moving
into Directus is mostly a matter of pointing it at an existing database and refining the Studio presentation; there is no content import step because the data is already there. Moving
out is equally clean: since your data lives in standard SQL tables, you can query, export, or front it with another tool at any time. The one caveat is Directus's own internal tables (roles, permissions, activity, presets) — those are Directus-specific and do not port to another CMS, but they are metadata about how you managed data, not the data itself. For a sovereign operator, this portability is the real insurance policy: adopting Directus never puts your content in a format only Directus can read. That is precisely the failure mode database-generated CMSes inflict, and Directus avoids it by design.
25. Performance and Scaling
Directus is a Node.js application, so its performance profile differs from a compiled binary. Under light load — the typical homelab or small internal tool — it is comfortably fast on a single small instance. As traffic grows, the levers are conventional: a Redis cache layer reduces database round-trips, database connection pooling prevents exhaustion, and horizontal Directus replicas behind the proxy share load once sessions and cache are externalized. The database remains the dominant scaling factor; Directus is a smart client to it, not a replacement. The practical advice is to size the database generously, add Redis early, and only add Directus replicas when a single instance's CPU is the bottleneck. Most self-hosters never reach that point, but the path exists without re-architecting.
26. Common Pitfalls
A short list of mistakes recurs. Hand-editing Directus's internal tables directly, rather than through the Studio or API, corrupts metadata and breaks upgrades. Granting the public role broad read access "just to test" and forgetting to lock it down. Treating Flows as a replacement for a real queue when workloads are heavy. Pointing storage at local disk on a container that gets recreated, silently losing uploaded files. Skipping database backups because "Directus handles it" — it does not; your database is the source of truth and the thing you must back up. And the license pitfall we opened with: deploying in production above the revenue/employee threshold without a commercial license. None of these are exotic; they are the ordinary ways a powerful tool gets misused, and each is avoidable with the discipline this article has emphasized.
27. A Concrete Walkthrough: A Small Blog Backend
To make the model concrete, imagine standing up a blog backend. You create
posts,
authors, and
categories tables in PostgreSQL with foreign keys. Point Directus at the database; the Studio immediately shows three collections with the right relations. You define an
author role that can create drafts but only publish their own, an
editor role that can publish anyone's, and a
public role that reads only
posts where
status = published. You enable the GraphQL endpoint so your frontend queries exactly the fields it needs. You add a Flow that, on
post publish, posts a webhook to your n8n automation (covered in this series) to syndicate the link. Within an afternoon you have a permissioned, API-exposed, self-owned content backend — with no backend code written and no lock-in, because the data was always just tables in your database.
28. Backups and Disaster Recovery
Because your database is the single source of truth for both your content and Directus's configuration, backup strategy is not optional — it is the backbone of operating Directus safely. The minimum viable practice is a nightly dump of the entire database (both your collections and Directus's system tables) stored off-host, plus periodic snapshots of the asset storage bucket if you use S3 or a copy of the local upload directory if you use disk. Test restore at least once: a dump you have never restored is a hope, not a backup. For higher assurance, add continuous archiving (WAL shipping for Postgres) and point-in-time recovery so a bad Flow or mistaken bulk edit is reversible. Redis, being a cache and session store, does not need the same rigor, but if you rely on it for real-time state, include it in the plan. The reassuring part is that none of this is Directus-specific — it is standard database operations, and the database-first model means your recovery path is "restore the SQL dump and point Directus at it," with no proprietary export format to wrestle. Directus's documentation and community forum are active enough that most operational questions have a known answer, which lowers the lifetime cost of owning the platform. Pair the database backups with configuration-as-code for your policies where possible, and your recovery story stays boring — which is exactly what you want from infrastructure. The database-first design is the reason this is achievable, and it is the reason Directus remains a sovereign-friendly choice even under a source-available license.
Related
For the rest of a sovereign, self-hosted stack, these pieces from our series travel with Directus:
Comments (0)
No comments yet. Be the first to comment!