Which fits your Contentful situation: Contentful or Directus?
Teams usually ask this question when a Contentful renewal arrives or when data residency rules say that content, user records and media must sit on infrastructure the organization controls. The answer depends on whether you want a managed content platform or a CMS layered on a database you already operate. Contentful fits teams that want a hosted content platform and do not want to run a database. Directus fits teams that already run PostgreSQL, MySQL, MariaDB, Microsoft SQL Server or another supported SQL engine and want REST and GraphQL APIs and the Studio interface on top of that existing schema. Directus connects through the DB_CLIENT setting, so the database choice is yours to make and to defend in an audit.
The first driver is license terms. Directus is licensed under the Monospace Sustainable Core License 1.0, which is not an OSI open source license. It permits internal use but bars a Competing Use against Monospace's paid offerings, and each version converts to GPL-3.0 four years after release. Have legal review whether your planned use, including any product you plan to sell to customers that resembles a CMS or data service, falls inside that limit before you commit. The second driver is who runs the database and media storage. With Directus, your team owns backups, patching, replication, and the storage behind uploaded assets, so confirm those responsibilities with the people who would carry the pager.
The third driver is team skills. Directus suits a team that is comfortable with SQL, schema migrations and Docker-based operations, and its Studio helps non-technical editors. Contentful suits a team that wants content modeling handled by a vendor and accepts that the content model and delivery live in someone else's platform. Ask your team which of these skills it already has, and request a written scope from any implementation partner that lists who owns each operational duty after go-live.
Which option fits which scenario
This table matches common situations to the option that usually fits better and explains why. Read each row as a starting point, then test it against your own database estate, licensing constraints and editorial workflow. The main takeaway is that Directus suits teams that already own a SQL database and want to keep data there, while Contentful suits teams that want a managed service with no database to run.
| Scenario | Better fit | Reason and trade-off |
|---|---|---|
| Existing PostgreSQL or SQL Server estate | Directus | Directus connects to your existing database through its DB_CLIENT setting, so content lives next to other systems. You take on schema management, database tuning and backups that Contentful handles for you. |
| Need for a managed service with no database to run | Contentful | Contentful hosts the content model, APIs and asset delivery. Directus Cloud is a managed option, but it is a different commercial relationship. Confirm its terms with Directus before you rely on it. |
| Product that could compete with Directus's paid offerings | Contentful or a different CMS | The Monospace Sustainable Core License bars competing use against Monospace's paid offerings. If your product competes, get a written legal opinion before adopting Directus, or choose an OSI-licensed option. |
| Studio-led editorial team | Directus, if the team works from a data-first model | Studio is a management interface for non-technical teammates, and it sits directly on your tables. Contentful's editor is more mature for rich editorial workflows, so test both with real editors. |
| Team needing full control of data and hosting | Directus, self-hosted | Self-hosting with Docker keeps the database, files and API under your control. Contentful is a hosted SaaS, so you rely on its data residency and hosting terms. |
| Team with little database or DevOps capacity | Contentful | Directus self-hosting moves backups, upgrades, scaling and security patching to your staff or a partner. Price these operating tasks before comparing licence fees. |
| Content model that is mostly tables with relations | Directus | Directus generates REST and GraphQL APIs from the schema, so relational data maps directly. Contentful's content types suit structured editorial content but are not your own tables. |
What the Monospace Sustainable Core License means for your product
Directus is not open source under the OSI definition, and that changes the legal question you need to answer before you build on it. Directus is licensed under the *Monospace Sustainable Core License* (MSCL-1.0-GPL). The license permits any use except a Competing Use against Monospace's paid offerings, and it allows internal use. Each version converts to GPL-3.0 four years after release. The practical test is whether your product, once built on Directus, sells a service that competes with Directus Cloud or another paid Monospace offering. Internal content operations, a company website, or a customer-facing app that is not a competing hosted product generally sits outside that line, but the definition of Competing Use is the clause your counsel must read word for word.
The license has also changed twice in a short period. According to the commit history of the license file in the directus/directus repository, Directus moved to BSL-1.1 in April 2023 and replaced that license with the Monospace Sustainable Core License in 2026. Ask Directus which license governs each version you deploy, and pin the version in your deployment record so the terms you reviewed are the terms you run. Check whether any code, extensions or themes your team writes or buys carry their own license, and whether a future change to the license would affect a product you plan to sell for years.
Treat this summary as a starting point, not as legal advice. Before committing, send the license file and your product plans to counsel, and ask Directus in writing to confirm how it reads Competing Use for your specific use case, including any resale, white-label, embedded or managed-service model. Keep the written answer with your procurement file. If counsel finds the terms unclear for your plans, compare the options on the rest of this page against a license your lawyers are comfortable with before you start the migration work.
Where your content and database live under each option
Contentful and Directus differ mainly in who holds the content store, who runs the database, and who produces the evidence an assessor will ask for. The cards below cover the decisions that follow from those differences, so you can check each one against your residency rules and operating model before you commit.
Data location and residency
With Contentful, entries, assets and the delivery layer sit in Contentful's hosted environment, so you depend on its contracted regions and sub-processors for residency. With Directus, the data sits in whichever SQL database you point DB_CLIENT at, which means the region is the one you choose in your own cloud account or data center. Ask Contentful in writing where each space is stored and which sub-processors touch it, and map your own database and asset storage to the residency commitments you have made to customers.
Who operates the database and backups
In a Contentful space, the vendor runs the content store and you export it when you need a copy. With Directus, your team or your implementation partner owns the PostgreSQL, MySQL or other SQL instance, its patching, replication, point-in-time recovery and restore tests. Write down who restores a database, how often a restore is tested, and where the asset files are backed up, because Directus does not hold those responsibilities for you.
Identity and role-based access
Directus enforces its own roles and permissions, and its native MCP server and AI Assistant run under those same permissions as human users. Contentful manages roles, memberships and permissions in its own console, and its CLI space export does not carry roles or permissions across. Decide which identity provider signs in your editors, how roles are assigned and reviewed, and who can change permissions, then test that an AI integration cannot read content the user cannot read.
Audit evidence the team must produce
A hosted SaaS vendor usually supplies some access and change history, but the scope and retention depend on the plan and the contract. With Directus, the logs for the application, the database and the reverse proxy are yours to collect, retain and protect. Confirm with Contentful which activity logs are available, how long they are kept and how you export them, and plan where Directus logs will be stored and who can read them.
Hosting models to compare
Contentful is delivered only as its hosted SaaS. Directus can run self-hosted with Docker on your cloud account or on-premise hardware, or run on Directus Cloud as a managed service. Each choice moves a different set of patching, scaling and availability duties to your side or to the vendor. Ask for the Directus Cloud data location and sub-processor list if you consider it, and treat a Docker deployment as a platform you must maintain.
Compliance readiness work
Moving to Directus shifts the work of preparing controls, policies and evidence to your team, and DeployOpen can help prepare systems and evidence for an assessment. Independent auditors, not DeployOpen or either vendor, decide whether the controls meet a framework. Identify which of your obligations depend on the CMS, such as access reviews, change management and backup testing, and confirm with your assessor which evidence they will accept before you migrate.
What a move from Contentful to Directus involves
The sequence moves a Contentful space into a Directus instance on your own SQL database, with each step ending in a check that the content, access and consumers match the source. Roles and permissions are not in the Contentful export, so they are rebuilt by hand and tested before cutover.
Inventory the space and its consumers
Your team lists every content type, locale, asset collection, webhook and environment in the Contentful space, then records which front ends, scripts and integrations call its delivery and management APIs. Confirm the owner of each consumer and whether it reads published or draft content. The step is done when the inventory is signed off by content, engineering and the business owner of each consumer, because it sets the scope of every later step.
Export the space with the Contentful CLI
An engineer runs the Contentful CLI space export command to capture the published content model, entries, assets, locales, webhooks and editor interfaces as JSON, and downloads the asset files. The export does not include roles or permissions, so those are recorded separately from the Contentful web app. The step is done when the export file opens cleanly, entry and asset counts match the Contentful web app, and the export is stored in a location your security team controls.
Map content types to SQL tables
A data modeler maps each Contentful content type to a table, each field to a column or a related table, and each reference field to a foreign key, then decides how rich text, localized fields and linked assets are stored. Directus reads the schema from the database, so the mapping is the design decision that the rest of the move depends on. The step is done when the mapping document is reviewed by the content team and the engineers who own the consumers, and every field in the inventory has a target column or an explicit reason it is dropped.
Stand up Directus against the target database
Platform engineers deploy Directus in your own infrastructure, with Docker or your existing container platform, and point it at the target PostgreSQL, MySQL, MariaDB, Microsoft SQL Server or other supported database through the DB_CLIENT setting. They create the tables from the mapping, apply backups and access controls, and confirm that Directus generates the REST and GraphQL endpoints from that schema. The step is done when a test record can be created, read and deleted through both APIs from a staging environment.
Import entries and assets
Engineers write an import script that reads the export JSON, resolves references between entries, transforms rich text into the format your front ends expect, and uploads asset files to your chosen storage. Localized fields are loaded per locale. The step is done when a sample of entries from each content type matches the Contentful source field by field, every reference resolves, and asset URLs load from the new storage.
Rebuild roles and webhooks by hand
Because the Contentful export does not carry roles or permissions, administrators recreate each role in Directus, set collection-level and field-level permissions to match the recorded Contentful roles, and re-register webhooks that trigger builds or notify other systems. Directus applies the same role-based permissions to its native MCP server and AI Assistant, so those access rules are set here too. The step is done when a test account for each role can perform exactly the actions the old role allowed and nothing more.
Test API consumers against the new endpoints
Each consumer identified in the inventory is pointed at a staging Directus instance and tested for response shape, filtering, pagination, locale handling, preview of unpublished content and error behavior. Teams fix any client that depended on a Contentful-specific response format. The step is done when every consumer passes its test suite and the content team confirms that editors can publish and preview in Directus Studio.
Cut over and retire the Contentful space
The team freezes content edits in Contentful for the cutover window, runs a final export and import, switches consumers to the production Directus endpoints, and keeps the Contentful space read-only for a retention period set by your records policy. The Contentful space is removed only after the retention period and a final backup are confirmed. The step is done when production traffic is served from Directus, the final export is stored, and the Contentful subscription change is recorded with the finance team.
Questions buyers ask before choosing Directus or staying with Contentful
How much effort does moving from Contentful to Directus take?
The effort depends mostly on how many content types, locales, references and assets you have, and on how far your frontend depends on Contentful's delivery API and its response shapes. Directus builds its REST and GraphQL APIs from your database schema, so the work is mapping content types to tables, importing entries and assets, and rebuilding the frontend queries. Contentful's space export covers the content model, entries, assets, locales, tags and webhooks, but not roles or memberships, so access rules are a separate piece of work. Ask any implementation partner to size the work from a written inventory of your content types, integrations and frontend consumers before agreeing a scope.
Can our own team migrate from Contentful to Directus without outside help?
A team with strong SQL, API and frontend skills can often do the migration in-house, provided it has time for schema design, import scripting and testing. Teams without that depth, or without spare capacity during the cutover, usually bring in outside help for the schema mapping and the import. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure and works under a fixed scope agreed in writing, so you can keep the parts your team wants to own and hand over the rest. A useful first step is an internal review of your Contentful content model against a Directus data model.
How long does a Contentful to Directus migration take?
The timeline is set by the scope of your content model, the volume and quality of your existing content, the number of integrations, and how much testing your frontend and editors need before cutover. No duration can be stated here without a written inventory, so treat any figure you hear before that point as unverified. Two items often extend the schedule: rebuilding roles that the export does not carry over, and resolving rich text and reference fields that do not map cleanly into SQL tables. Ask for milestones tied to content types, environments and cutover rehearsals rather than a single end date.
Does the MSCL license stop us from using Directus in our product?
Directus is licensed under the Monospace Sustainable Core License 1.0 (MSCL-1.0-GPL), which permits any use except a Competing Use against Monospace's paid offerings. Internal use of Directus to run your own content operations is allowed, but offering Directus itself as a competing hosted or managed product is not. Each version converts to GPL-3.0 four years after release. Because the license is not an OSI open source license, have your legal team review the license file against your specific use, especially if you plan to resell or embed Directus in a customer-facing service.
Can Directus run on our existing SQL database?
Yes. Directus connects to an existing SQL database and supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB, selected through the DB_CLIENT setting. It generates REST and GraphQL APIs from that schema, so it can sit on top of tables your organization already maintains. Confirm with your database team which engine and version you run, how backups and replication are configured, and whether a separate database should hold Directus system tables. Directus is a layer on your data, so schema changes in the database affect what the APIs expose.
Which Contentful features need rebuilding in Directus?
Several Contentful features do not carry over as-is and need a deliberate replacement. These typically include:
- Roles, memberships and per-space permissions, which the export does not include and which you rebuild as Directus roles and policies
- Webhooks and their credentials, which you re-create in your automation or integration layer
- UI extensions and custom editor interfaces, which have to be rebuilt for Directus Studio
- Preview and draft workflows, which depend on how your frontend fetches unpublished content
Confirm the exact list against your own space by comparing the export with your current roles, extensions and webhook configuration.
What do our engineers and content owners need to commit to this move?
Engineers need time for schema design, import scripting, API query changes in the frontend, environment setup and security review of the self-hosted stack. Content owners need to validate that migrated entries, references, locales and assets display correctly and that their editing workflows still work in Directus Studio. Plan for named owners on both sides and a test window where Contentful and Directus run in parallel. Keep the decision on whether to self-host Directus with Docker or use Directus Cloud as a separate, explicit choice, since it changes who operates the database, upgrades and backups.
What running Directus shifts onto your team
Running Directus moves the operating work that a hosted CMS vendor handles today onto your team. The most important shift is that you own the database. Directus sits on top of a SQL database you already run or choose, through the DB_CLIENT setting, so backups, patching, replication, connection limits, and capacity planning become your responsibility. Directus stores its own system tables alongside your content, so schema changes made in Studio or through the API need the same change control you apply to any production database. Before committing, confirm which engine your team already operates well (PostgreSQL, MySQL, MariaDB, Microsoft SQL Server and others are listed in the database configuration documentation) and who holds on-call responsibility for it.
Upgrades are the recurring cost most teams underestimate. Directus ships on a steady cadence: 12.4.0 was released on September 22, 2026 and 12.5.0 followed on October 7, 2026, according to the GitHub releases page. Plan for a staging environment that mirrors production, a test pass over your custom extensions, flows and API consumers, and a rollback path that includes a database backup taken immediately before the upgrade. Backup and recovery also differ from a SaaS model because you must test restores, not just schedule them. Asset storage, access control through roles and permissions, and monitoring of the API and database round out the list. Ask any implementation partner to show the upgrade runbook and a restore test before you sign off.
This is a small load when your organization already runs production databases with tested backups, patch windows, and monitoring, and when the CMS is one more application on that estate. It becomes a burden when no one owns the database, when content editors depend on a single instance with no tested recovery, or when the CMS must meet audit expectations for change control and access reviews that nobody has yet documented. Decide early who performs each task, how often, and what it costs in staff time, and compare that against the Contentful subscription you are replacing. Illustratively, a team that already patches PostgreSQL monthly may add a Directus upgrade to the same window, while a team without that practice will need to build it first.
How DeployOpen helps you evaluate, implement and migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Contentful vs Directus decision, we work from a written scope that covers the license terms, data model and hosting choices before any build begins.
How we scope
- We confirm which Contentful spaces, content types and locales are in play and how many environments you run.
- We review the Directus MSCL-1.0-GPL terms against your intended use, including whether any part of your work could count as a Competing Use.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We map Contentful content types to SQL tables on your chosen database, such as PostgreSQL or SQL Server, and document each relationship.
- We configure Directus with the DB_CLIENT setting, set up REST and GraphQL access, and test role-based permissions against real editor workflows.
- We stand up the Docker-based deployment in your environment and test the asset storage, backups and restore path before cutover.
How we hand over
- You receive the schema map, permission model, deployment configuration and runbooks for upgrades and backups.
- We document which Contentful items the space export does not carry over, such as roles and webhook credentials, and how each was rebuilt.
- We prepare control and evidence documentation for your compliance team, which independent auditors then assess.
How we support
- Ongoing support, Directus upgrades and continuous security testing are available as retainers after handover.
- We track Directus releases and plan upgrade windows with your team so your environment stays current.
- Confirm with DeployOpen during scoping which support hours, response paths and retainer terms apply to your environment.
