Strapi vs Directus: when each fits and what decides the choice
Choose Strapi when your team is starting a new content schema and wants MIT-licensed community code at the core. Choose Directus when you need to put a headless API and admin interface in front of an existing SQL database under the Monospace Sustainable Core License. Both are self-hosted, both expose APIs, and both can serve a developer team, so the decision rarely comes down to features. It turns on three factors: license terms, whether you model content from scratch or connect to data you already have, and which databases you must run on. Whichever of these three is non-negotiable for your organization will usually settle the choice before you compare anything else.
Start with license terms, because they are the factor most likely to reach legal review. Strapi's Community Edition code outside ee/ directories is under the MIT Expat license, while ee/ directories carry a proprietary Enterprise license. Directus is under the Monospace Sustainable Core License 1.0, which permits any use except a Competing Use against Monospace's paid offerings. Ask your counsel to read the Directus license text against your intended use, including whether you plan to build a product that competes with Directus's paid services. Also confirm how each license applies to the specific modules and extensions your team intends to deploy, since the boundaries differ.
Next, check the data model and database list against your environment. Directus connects to an existing SQL database and selects its engine through the DB_CLIENT setting, with support listed for PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite, and does not support MongoDB or other NoSQL databases. If you must run on Oracle or SQL Server, that alone narrows the field. Confirm the exact versions your database team supports in the Directus database configuration documentation before you commit, and plan a test against a copy of your production schema.
Which headless CMS fits which team: Strapi vs Directus by scenario
This table maps common team situations to the platform that fits each one better, with the reason for each choice. Read the reason column first, because the same requirement can point either way depending on whether your database or your code is the source of truth. Neither platform is universally better: Directus suits teams where the database is the source of truth, while Strapi suits teams that define the schema in code and accept its paid tiers for the features they need.
| Scenario | Better fit | Reason |
|---|---|---|
| Illustrative: a payments firm starting a new content model owned by developers | Strapi | Schema defined in code fits developer-led modeling, provided the team accepts Growth or Enterprise pricing for paid features. |
| An existing SQL database that other applications already write to | Directus | Directus connects to the existing database as the source of truth and lists Oracle and Microsoft SQL Server, which Strapi 5 does not list. |
| A license review that rejects non-OSI terms | Strapi | Strapi Community code outside ee/ directories is MIT. Directus uses the MSCL, which restricts Competing Use. Confirm the terms with legal. |
| A team of non-developers editing content | Directus | Studio is built for non-technical teammates. Test Strapi's admin panel with your actual editors before deciding. |
| A need for MongoDB | Neither | Strapi 5 excludes MongoDB and other NoSQL databases, and Directus does not list MongoDB among its supported databases. Evaluate other platforms. |
| An organization that needs SSO for editors | Strapi, on a paid plan | Strapi SSO covers admin panel login through an identity provider on Growth (add-on) or Enterprise. Confirm Directus SSO support for your editors. |
How Strapi and Directus are built and what that means for operations
Strapi and Directus both expose REST and GraphQL APIs, but they start from different places: one defines the schema in code, the other reads it from a database. Those choices decide who owns migrations, where backups must reach, and what your team must run and patch.
Schema definition model
Strapi 5 is code-first: content types are defined in the project and changes ship through your codebase and version control. Directus is database-first: it connects to an existing SQL database and reads its tables, so schema changes are made against the database itself. For Strapi, developers own schema migrations in Git. For Directus, confirm how schema snapshots are captured and promoted between environments before you commit to a workflow.
API layer and generated endpoints
Both platforms generate REST and GraphQL APIs. Directus builds them from the database schema, so the API tracks whatever tables and columns exist. Strapi builds them from the content types defined in code. Check how each handles response format, versioning and breaking changes for your front ends, since Strapi 5 changed its API response format from v4.
Admin interface for teammates
Strapi provides an admin panel aimed mainly at developers and content editors who work within its content types. Directus provides Studio, a management interface designed for non-technical teammates to manage data directly. If editors need to work in the data model without developer help, test Studio with your real roles. If your editors only manage defined content types, the Strapi admin panel may be enough.
Runtime and deployment footprint
Strapi 5 runs only on Active or Maintenance LTS Node.js versions, so your team must track Node.js lifecycles and rebuild when the runtime changes. Directus can be self-hosted with Docker, which moves much of the runtime definition into container images. Ask each vendor for the exact supported runtime matrix and container image process, then align it with your patching and image-scanning standards.
Backups and database ownership
In both platforms the database holds the content, so backups must cover it before any upgrade. Strapi's migration guidance tells you to back up the database first because downgrading is not supported. With Directus, which connects to your existing SQL database, your backup and restore procedures must cover that database and any files it references. Confirm recovery point and restore testing with the teams that own the database.
Managed hosting options
Strapi Cloud and Directus Cloud are optional managed services, and self-hosting stays available for both. Strapi Cloud pricing is per project, and its plans include a stated uptime SLA on the top tier. Choosing a managed service changes who patches the runtime and who holds the database, so compare region, backup coverage and exit terms against your own infrastructure rules before deciding.
How Strapi vs Directus compares on databases, licensing and features
This table sets Strapi and Directus side by side on license, edition split, databases, connection model, APIs, admin tooling, AI features, governance features and latest release. Read it as a checklist: a row marked with a dash or a note to confirm is a gap in the supplied facts, so verify it with the vendor before you decide. The main takeaway is that the license and the database starting point are the two rows most likely to settle the choice.
| Capability | Strapi | Directus |
|---|---|---|
| License | MIT Expat for Community code outside ee/ directories; ee/ directories under a proprietary Strapi Enterprise license | Monospace Sustainable Core License 1.0 (MSCL-1.0-GPL), converting each version to GPL-3.0 four years after release |
| Community or Enterprise split | Community (free) plus paid self-hosted Growth and Enterprise plans, with Growth listed per seat | Single licensed codebase; confirm with Directus which features, if any, sit behind paid Directus Cloud or support tiers |
| Supported databases | PostgreSQL 14 or later, MySQL 8.0 or later, MariaDB 10.3 or later, SQLite 3; no MongoDB or other NoSQL | PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite, CockroachDB via DB_CLIENT |
| Existing SQL database connection | Designed around Strapi's own content schema; confirm how it handles an existing database with your tables before you commit | Connects to an existing SQL database and generates APIs from its schema |
| API types | REST and GraphQL on all self-hosted plans | REST and GraphQL generated from the database schema |
| Admin interface | Strapi admin panel for content editors and developers | Studio, a management interface built for non-technical teammates |
| AI features | Confirm current AI tooling with Strapi; not covered in the supplied facts | Native MCP server and embedded AI Assistant, both operating under the same role-based permissions as human users |
| Audit logs and review workflows | Enterprise plan feature | Confirm with Directus whether equivalent governance features exist and under which tier |
| Content history and releases | Available from the Growth plan and above | Confirm with Directus before relying on version history or scheduled releases |
| Latest release | Strapi 5.58.0, published October 14, 2026 | Directus 12.5.0, released October 7, 2026 |
What the Strapi and Directus licenses allow, and what each paid tier adds
Strapi splits its licensing by directory. Code outside the ee/ directories is provided under the MIT Expat license when you have no Strapi Cloud account, so a self-hosted team can run and modify that code without a fee for the Community Edition. Code inside ee/ directories carries a proprietary Enterprise license, which applies only when you use those features.
- Community tier: Free, with unlimited users, and it includes REST and GraphQL APIs and unlimited entries and API calls.
- Growth tier: Listed at 45 US dollars per month including 3 users, plus 15 dollars per extra user, according to the Strapi self-hosted pricing page. SSO is an add-on at this tier, and content history and releases start here.
- Enterprise tier: Custom pricing. Audit logs, review workflows and enterprise plugins require this plan.
- Cost drivers: Seat count, which features you need, and whether you add SSO on Growth or move to Enterprise.
- Quote request: Ask Strapi for a written quote that lists the seats, add-ons and support level you expect.
Confirm with your legal team which directories your build actually includes, because the boundary between MIT and proprietary code determines which features you can run without a paid plan.
Directus is licensed under the Monospace Sustainable Core License 1.0 (MSCL-1.0-GPL). The license permits any use except a Competing Use against Monospace's paid offerings, and each version converts to GPL-3.0 four years after its release, according to directus.com/license and the repository license file. The license history matters as much as the current text.
- Permitted use: Any use that is not a Competing Use, which covers most internal and product use cases.
- Competing Use: Whether your product competes with Monospace's paid offerings needs legal review against your own product and business model.
- Conversion: Each version becomes GPL-3.0 four years after release.
- License history: Directus changed its license to BSL-1.1 in April 2023 and replaced it with the Monospace Sustainable Core License in 2026, according to the commit history of the license file.
- Pricing: Directus pricing was not in the sources reviewed for this page. Request current paid tier pricing and feature lists from Directus in writing.
Before you commit, have counsel read the current license text, not a summary, and document how your product relates to Monospace's paid offerings.
License risk comes from three sources: a restriction on how you can use the software, a change to the license after you adopt it, and a feature gap that pushes you onto a paid tier. Each platform carries a different mix. Strapi's risk sits mainly in the boundary between MIT and enterprise directories and in seat-based pricing. Directus's risk sits in the Competing Use clause and in its license history, which includes a 2023 change and a 2026 replacement.
- Change history: Both projects have changed license terms or structure in recent years, so track the license file in each repository.
- Feature gating: Confirm which controls your compliance or audit process needs, such as audit logs or review workflows, and whether they sit in a paid tier.
- Seat growth: Model how Strapi Growth pricing changes as your editorial or developer team grows.
- Competing Use review: For Directus, treat this as a question for counsel, not an engineering decision.
- Exit planning: Ask what happens to your deployment if you later drop a paid tier or the license changes again.
Ask each vendor for its license commitments in writing and record the answers in your architecture decision record.
How SSO and end-user login differ between Strapi and Directus
Strapi's SSO covers administrator login to the admin panel only. An identity provider such as Microsoft Azure Active Directory can sign editors and administrators into the Strapi admin, with auto-registration of new users, a default role assigned at first login, and an optional local login lock-out that disables email and password access to the admin. On self-hosted plans, SSO is an add-on for Growth and is included in Enterprise, so a team that needs it on Growth should price that add-on before committing. Confirm the license tier in the Strapi self-hosted pricing page against your seat count, because the cost depends on how many people need admin access.
End-user authentication in Strapi is a separate concern. Your website or app users, customers or members sign in through the Users and Permissions plugin, which manages their accounts and the roles that gate API access. An identity provider that signs in your editors does not, by itself, authenticate the people who read or buy from your site. Map the two flows separately in your design: who the administrators are, how their roles are assigned, and how end users register, log in and receive permissions through the API.
For Directus, the supplied facts do not establish its SSO model, so this page does not claim parity with Strapi on any of these points. Before deciding, confirm three things in the Directus documentation and with the vendor: whether admin Studio login supports an external identity provider and on which plans, how end-user authentication is handled for the APIs Directus generates from your database, and how identity provider groups or claims map to Directus roles and permissions. If your identity provider must be the single source of truth for both editors and end users, test that exact flow in a non-production instance before you commit to either platform.
What drives the running cost of Strapi and Directus
The running cost of either platform is mostly labor and infrastructure, and the license line is often the smallest part. Strapi Community is MIT-licensed and free to run, so its recurring cost is the application host, the database, backups, and the people who keep them working. Directus is also free to self-host under the Monospace Sustainable Core License, but its terms restrict Competing Use, so confirm with Monospace that your planned use is permitted before you budget. For Strapi 5, the Node.js runtime must be kept on an Active or Maintenance LTS version, which means someone owns that upgrade cycle. For Directus, the Docker images, container orchestration and the database connection (DB_CLIENT) are the operational surface. Separately, if you choose Strapi Cloud, the listed plans are 35, 90 and 450 US dollars per month per project for Starter, Pro and Business, according to the Strapi Cloud pricing page, and each plan carries its own API, storage and bandwidth allowances to check against your traffic.
Paid tiers and upgrades add cost that recurs on a schedule you do not control. On self-hosted Strapi, the Growth plan is listed at 45 US dollars per month including 3 users, plus 15 dollars per extra user, according to the Strapi self-hosted pricing page. If your editorial team grows, seat charges scale with it, and SSO for administrators is an add-on on Growth but included in Enterprise. Audit logs and review workflows need Enterprise. Ask the vendor which of these features your workflow requires, because a small number of paid features can change the tier for the whole team. Upgrade labor also recurs. Strapi publishes a v4 to v5 migration tool with codemods, and Strapi 5 minor releases ship roughly weekly, so budget for regular patch testing. Directus releases follow a similar pattern, and its 12.5.0 release was published on October 7, 2026, according to the Directus GitHub releases page.
Separate the one-time build from the recurring run, and put both in the quote. One-time costs include schema design, data migration from an existing SQL database, the identity provider setup for administrators, and initial hardening. Recurring costs include hosting, backups, database and runtime upgrades, staff time and any support retainer. When you request a quote, ask for the scope of schema work (new content types for Strapi or introspection and permission design for Directus), the exact database versions to be supported, which features need paid tiers, and who owns upgrades after go-live. The quote should name who performs the backups and restore tests, because Strapi's migration docs say to back up the database first and that downgrades are not supported. DeployOpen does not publish prices, so request a fixed-scope written proposal that lists these items separately.
Moving content from Strapi to Directus, or the reverse, step by step
This sequence turns a switch between Strapi and Directus into a controlled cutover, with each step producing a checked artifact so the team knows when it can move on.
Inventory content types, relations and API consumers
The platform team lists every content type, field, relation, media library, locale and role in the current Strapi project, then lists every consumer that calls its REST or GraphQL endpoints, including front ends, mobile apps, scheduled jobs and partner integrations. Owners of each consumer confirm the endpoints and fields they read. This inventory is the baseline for every later step. It is done when each consumer has a named owner and each content type has a documented field list. Because switching cost grows with the number of API consumers, this list also sets the size of the rebuild.
Decide which database is the system of record
The architecture owner chooses the single database that holds authoritative content during the migration, and the team confirms it is one both platforms support. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite and does not support MongoDB or other NoSQL databases. Directus connects to an existing SQL database through its DB_CLIENT setting. Confirm the exact versions your environment needs against the current installation and database documentation. It is done when a written decision names the database, its backup owner and the direction of writes during the transition.
Map the schema to the target data model
The data modeler maps each Strapi content type to a Directus collection, or the reverse, and records how fields, components, dynamic zones, relations, draft and publish states, and localized fields translate. Strapi builds its schema in code, while Directus builds it from the database, so decide which side will own the schema definition after cutover. Run the mapping against a sample of real records in a non-production copy. It is done when the mapping document is signed off and every field has a target or a documented reason for dropping it.
Export or connect data and verify it
The engineering team moves content either by exporting from the source platform and importing into the target, or by pointing the target at the same SQL database where the data already lives. Strapi v4 projects use its upgrade tooling, including codemods, data migration scripts and a breaking changes list, but moving to Directus is not covered by that tooling and needs custom scripts. Before any transfer runs, take a full database backup, because Strapi's documentation says downgrading is not supported. Compare row counts, relation integrity and media references after each run. It is done when the counts and sample checks match the baseline from step one.
Rebuild roles, permissions and admin access
The security engineer recreates each Strapi role and public or authenticated permission as a Directus role and permission set, enforcing the same access rules for every collection and field. Directus applies role-based permissions to its REST and GraphQL APIs and to its native MCP server and AI Assistant, so any agent or automation account needs its own scoped role. Test each role with a real account and confirm that denied requests return denied responses. It is done when a test matrix shows every role's expected reads and writes, and the results are reviewed by the content owner.
Rebuild API clients and front-end queries
Each consumer owner updates their client to the target API's endpoints, query syntax, authentication and response shape. Strapi 5 changed its response format from v4, and the Strapi-Response-Format: v4 header exists only as a compatibility aid during migration, so teams moving in either direction should expect to rewrite client code rather than swap base URLs. Build the changes in a staging environment and keep the old endpoints live until cutover. It is done when every consumer in the step one inventory passes its integration tests against the target.
Reconfigure identity and single sign-on
The identity team reconnects administrator login to the identity provider for the target platform and confirms how auto-registration, default roles and any local login fallback behave. Strapi SSO covers administrator login to the admin panel, while end-user authentication is handled by its Users and Permissions plugin, so end-user accounts and passwords need a separate migration plan. Directus has its own authentication setup, which the team should confirm against current documentation. It is done when test administrators sign in through the provider and each end-user login path has been tested.
Run parallel verification before cutover
The team runs both systems side by side for a defined verification period agreed in the project plan, comparing published content, API responses for each consumer, permission outcomes and scheduled publishing. Discrepancies are logged with an owner and a fix date, and the rollback path stays documented. Confirm the verification window and exit criteria with the stakeholders before it starts, since no supplied timeline applies here. It is done when every discrepancy is closed and the sign-off group accepts the results in writing.
Cut over and retire the old platform
The operations lead switches traffic and writes to the target platform in a planned window, points each consumer at production endpoints, and keeps the source database read-only and backed up for an agreed retention period. The team confirms monitoring, alerts and backup jobs on the new stack and removes the old platform only after the rollback window closes. It is done when production traffic runs on the target, the source is archived under its backup policy, and the migration record lists every decision, owner and test result.
Where Strapi and Directus implementation projects usually run long
Most delays in Strapi and Directus projects come from decisions made before the first build sprint: the schema, the database, the Node.js runtime, and who can do what in the admin panel. Each card below names one risk, what to confirm in your own environment, and what the written scope should cover before work starts.
Schema redesign after launch
Strapi builds its data model from content types defined in code, while Directus generates its API from tables you already have. Either way, a model changed after content exists means migrating live records, updating every API consumer and retesting front ends. Confirm which content types, relations and locales are fixed before launch, and who signs off changes. A written scope should list the modeling workshop, the change-control rule for post-launch edits, and the test data used to validate each revision.
Strapi v4 to v5 migration work
If you are moving an existing Strapi v4 project, plan for more than a version bump. Strapi provides codemods, data migration scripts that run on first start of Strapi 5, and a breaking changes list, and it advises backing up the database first because downgrading is not supported. Strapi 5 also replaces the Entity Service API with the Document Service API and changes the response format, so custom code and front ends may need work. The Strapi-Response-Format: v4 header can help during transition. Confirm your custom plugins and API consumers, and scope the migration as its own deliverable with a rollback plan.
Database choice and driver differences
Strapi 5 runs on PostgreSQL, MySQL, MariaDB and SQLite, and does not support MongoDB or other NoSQL databases. Directus connects to an existing SQL database and also supports Oracle Database, Microsoft SQL Server and CockroachDB through its DB_CLIENT setting. Teams that already run a particular engine often find that Directus fits better, but the choice still affects SQL dialect behavior, backup tooling and the migration path. Confirm the engine version your platform team supports, the backup and restore procedure, and whether a staging copy of production data is available. The written scope should name the database, its versions and the test plan for each driver.
Node.js LTS alignment for Strapi
Strapi 5 runs only on Active or Maintenance LTS Node.js versions, so the runtime your organization has standardized on may not be supported by the Strapi release you pick. Upgrades to Node.js and to Strapi can then land in the same window, which doubles the regression surface. Confirm your approved Node.js version, your patching cadence for it, and how often your team plans to take Strapi minor releases, which have shipped roughly weekly. A written scope should specify the Node.js version, the pinned Strapi version, and who owns the upgrade calendar after go-live.
Permission model and role design
Strapi and Directus both enforce roles and permissions, but they split access differently. Strapi separates admin panel roles from end-user permissions handled by the Users and Permissions plugin, while Directus applies role-based permissions to human users, its MCP server and its AI Assistant alike. Late role design usually means rewriting policies after editors have already been granted too much or too little access. Confirm the roles your editors, reviewers and integrations need, and which actions must be audited. The written scope should include a role matrix, test accounts for each role and the process for approving permission changes.
Identity setup for admins and editors
Admin login is where many projects stall. Strapi SSO covers administrator login to the admin panel through an identity provider such as Microsoft Azure Active Directory, with auto-registration, a default role and an optional local login lock-out. It does not handle end-user authentication, which sits with the Users and Permissions plugin. In Strapi's self-hosted plans, SSO is an add-on for Growth and included in Enterprise. Confirm which plan your organization has licensed, the identity provider you will federate with, and how Directus admin and editor accounts will be provisioned. The written scope should cover the identity provider configuration, the default role mapping and the break-glass access plan.
Questions buyers ask before choosing Strapi or Directus
Which is cheaper to run, Strapi or Directus?
Neither license fee settles the question on its own, because both platforms can be self-hosted. Strapi's Community Edition is MIT licensed with unlimited users. Its Growth plan is listed at 45 US dollars per month including 3 users, plus 15 dollars per extra user, according to Strapi's self-hosted pricing page. The figures for Directus are not part of this comparison, so confirm its current terms with Directus in writing. Recurring costs come from paid seats, hosting, the database, backups, and the staff hours spent on Node.js upkeep and upgrades. Ask for a total cost model across the period you plan to run the system, not a single license line.
How long does a headless CMS implementation take?
No fixed duration applies to every project, and the answer depends on scope. The main drivers are the number of content types, the volume and quality of any existing data to migrate, the admin and end-user authentication design, roles and permissions, the front end that consumes the API, and how many environments you need. Review workflows and content history add work if you plan to use them. DeployOpen's engagements are usually fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for milestones tied to those deliverables, and ask what the plan assumes about your data and approvals.
Can a developer team build a headless CMS without outside help?
A capable developer team can build either platform in-house, because both are documented and self-hosted in your own infrastructure. The work that often gets underestimated is operational: keeping the Node.js runtime on a supported LTS line for Strapi, running database administration, testing backup and restore, configuring admin single sign-on, and training non-technical editors on the admin interface. Directus includes Studio for non-technical teammates. Outside help is most useful for a fixed-scope build, an upgrade plan, or a retainer for ongoing support and upgrades, which DeployOpen offers alongside its implementation work.
Can Directus sit on an existing SQL database?
Yes. Directus connects to an existing SQL database through the DB_CLIENT setting and supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB, according to the Directus database configuration documentation. Before you commit, confirm how Directus will read and manage your current schema, which tables it will touch, how permissions apply to existing rows, and how you will test on a copy of production data. Also confirm that your database engine version meets Directus's current requirements. A written migration and rollback plan should be part of the scope.
Does the Monospace license block a commercial product?
The Monospace Sustainable Core License 1.0 permits any use except a Competing Use against Monospace's paid offerings, according to directus.com/license. Whether your product counts as a Competing Use is a legal question, not a technical one, so get counsel to review the license text against your product, its customers and its positioning before you build on it. Each version converts to GPL-3.0 four years after release. Directus also changed its license in the past, from BSL-1.1 in April 2023 to the Monospace license in 2026, so ask counsel how a future change would affect your deployment.
Can Strapi or Directus run on MongoDB?
Not with Strapi 5. Strapi 5 supports MySQL, MariaDB, PostgreSQL and SQLite, and it does not support MongoDB or other NoSQL databases, according to the Strapi installation documentation. The Directus database configuration lists PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB, and no NoSQL database appears in that supported set. If MongoDB is a hard requirement for your organization, remove both from the shortlist unless the vendor confirms a supported path in writing. If the requirement is flexible, a relational database is the path both platforms document.
How often do Strapi and Directus ship upgrades, and what does that mean for staff?
Both projects ship often. Strapi 5 minor releases have arrived roughly weekly, including v5.56.0 on September 30, v5.57.0 on October 7 and v5.58.0 on October 14, 2026, according to Strapi's GitHub releases page. Directus released 12.4.0 on September 22 and 12.5.0 on October 7, 2026. Staff need a named owner, a staging environment, a tested backup before each upgrade, and a rule for which releases you adopt. Strapi's own migration guidance says downgrading is not supported, so the backup is your only way back. Ask any partner how upgrades are priced into a retainer.
What should I ask a consultant for in a quote?
DeployOpen does not publish a price list. A quote follows from a written scope, and most engagements are fixed-scope. Ask for a list of deliverables and exclusions, the target environment (cloud account, data center or air-gapped network), the database choice and a plan for any existing data, the authentication design for admins and end users, a tested backup and restore, an upgrade approach that matches the release cadence, and handover documentation. Also ask whether support or upgrades are a separate retainer, and confirm that licensing questions go to your own counsel.
How DeployOpen helps choose, implement or migrate a headless CMS
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Strapi or Directus decision, that means starting from your licensing position, your existing database and your delivery workflow before any build begins.
How we scope
- Confirm which license terms your legal and procurement teams must approve, including the Strapi Enterprise license for ee/ directories and Directus's Competing Use limit.
- Record whether you start from a new content schema or connect to an existing SQL database, and which database engine and version you run.
- Agree the written scope, deliverables and timeline in writing before any work starts, since most engagements are fixed-scope.
How we build
- Set up the chosen CMS in your infrastructure, with the database, Node.js runtime and admin login configured to your environment.
- Model content types or map the existing schema, then configure roles and permissions for editors, developers and API consumers.
- Test API responses, admin access and the integrations you specify, and document the security and access-control findings.
How we hand over
- Deliver architecture notes, configuration records, backup and restore procedures and an upgrade runbook for your own team.
- Walk your engineers through the admin panel, API setup and deployment pipeline so ownership sits with your team from day one.
- Provide the evidence and documentation your compliance reviewers will ask for, without claiming that it constitutes an audit or certification.
How we support
- Ongoing support, version upgrades and continuous testing are available as a retainer after the fixed-scope work closes.
- Ask for a retainer scope that names which CMS versions, database patches and Node.js runtime changes it covers.
- Confirm response expectations and upgrade handling in writing with DeployOpen before signing, since no standard service levels are assumed here.
