Should you self-host Directus or pay for Directus Cloud?
Choose Directus Cloud when your team is small, can accept a managed database, and does not need to keep the data inside its own network. Choose self-hosting when residency rules, an existing SQL estate or an air-gapped or private cloud constraint decides where the database lives. Before either option, check the free self-hosting rule, because it can remove the license cost from the decision entirely. Directus is licensed under the Monospace Sustainable Core License 1.0, and its pricing page says organizations under 5 million US dollars in annual revenue and fewer than 50 employees qualify for free self-hosting with no feature limits under the Open Innovation Grant. Confirm your revenue and headcount against that wording on the Directus pricing page and in the Directus license text, and confirm with Directus whether your organization is a Competing Use before you assume the grant applies.
Directus Cloud is a managed add-on priced at 99 US dollars per month on top of the Core and Team plans, according to the same pricing page. For that fee the vendor runs the hosting, so your team does not need to size a container host, manage a DB_CLIENT connection to a database, or schedule upgrades across releases such as 12.5.0, released on October 7, 2026. The trade-off is that the database sits in Directus's environment. If your data must stay in your own network, or your security team requires control over backups, encryption keys and restore testing, the managed option may not meet the requirement. Ask Directus, in writing, where Cloud data is stored, who can access it, and how backups and restores are handled.
Self-hosting with Docker on your own SQL database (PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle Database, SQLite or CockroachDB) suits teams that already run those engines and want Directus inside their existing controls. Those teams own the database, storage, backups, patching, TLS and every upgrade, and that work recurs for as long as the instance runs. Before choosing, have your platform team confirm the database version they can support, the storage and backup design, and who is on call for a failed upgrade. If the answer to any of these is unclear, an implementation partner can scope the work in writing before you commit.
How the two hosting models compare on cost, limits and control
This table sets Directus Cloud against self-hosting Directus with Docker on your own SQL database, row by row on price, free-use eligibility, database, hosting location, upgrades and license. Read each row as a question to answer for your organization before you choose the hosting model.
| Factor | Directus Cloud | Self-hosted Directus with Docker |
|---|---|---|
| Published price | Cloud is a 99 US dollars per month add-on to the Core and Team plans, per the Directus pricing page. Enterprise cloud is custom-priced. | No hosting add-on fee from Directus. You pay for your own servers, database, storage, backups and the staff who run them. |
| Free use eligibility | Cloud is a paid service. Grant holders can use cloud hosting at 99 dollars per month, per the Directus pricing page. | Organizations under 5 million US dollars in annual revenue and fewer than 50 employees qualify for free self-hosting with no feature limits under the Open Innovation Grant, per the Directus pricing page. Confirm your eligibility before you rely on it. |
| Seat and collection limits | Limits differ by plan. Confirm current seat and collection limits on the pricing page rather than assuming them. | Limits differ by plan. Confirm current seat and collection limits on the pricing page before you size a rollout. |
| Database | Managed by Directus. Ask which database engines are offered on Cloud before you plan your data model. | You connect an existing SQL database and select the engine through DB_CLIENT. Supported engines include PostgreSQL, MySQL, MariaDB, Microsoft SQL Server and SQLite. |
| Hosting location | Directus operates the hosting environment. Confirm the regions and data residency options in writing. | Runs in your own cloud accounts, data centers or private networks, so you control placement and network access. |
| Upgrades and patching | Directus manages the platform upgrade path. Confirm the upgrade schedule and any customer notice period in your contract. | You plan, test and apply each release, such as 12.5.0 released on October 7, 2026, per the Directus releases page, and own the rollback plan. |
| Backups and storage | Confirm backup frequency, retention and restore testing with the vendor. Confirm where file storage lives. | You own backup, restore testing, file storage and disaster recovery for both the database and uploaded assets. |
| License terms | Cloud use is governed by Directus's commercial terms. Read them with the Monospace Sustainable Core License in mind. | Directus is licensed under the Monospace Sustainable Core License 1.0, which permits any use except a Competing Use against Monospace's paid offerings and converts each version to GPL-3.0 four years after release. |
Where your data lives and what compliance means in each model
Directus Cloud and self-hosted Directus put the same database-first platform in different places, and the difference shows up in who holds the database, the backups and the access logs. Each card below is a decision or evidence question to settle before you compare the two models on paper.
Location of the SQL database and files
Self-hosting places the SQL database and any uploaded files in your own cloud account, data center or private network, which you select. On Directus Cloud, the managed service hosts the Directus instance and its data, so the physical location and network path are set by the vendor. Ask Directus which regions and facilities are used, where file storage sits, and whether data stays within the boundaries your regulator expects.
Who holds database credentials
With self-hosting, your team creates the database user, sets DB_CLIENT and the connection values, and controls rotation and who can read the secrets. In a managed model, the vendor operates the connection and you rely on its access controls and staff procedures. Confirm in writing which named roles at Directus can reach customer data, and how that access is approved and logged.
Backups, restores and retention
Self-hosted teams own the backup schedule, encryption, off-site copies and restore tests for both the SQL database and file storage. Under Directus Cloud, ask what backup frequency, retention period and restore process apply, who can request a restore, and whether backups are encrypted and where they are kept. Do not assume a retention default until the vendor states it.
Role-based access for MCP and AI Assistant
Directus says its native MCP server and embedded AI Assistant operate under the same role-based permissions as human users. That protects you only if the roles are scoped tightly in both models. Test an agent or assistant account against restricted collections before go-live, and confirm that the same permission model applies in a self-hosted deployment and on Directus Cloud.
Evidence an auditor will request
Auditors usually ask for a description of access controls, change records, backup and restore test results, and logs of administrative actions. Self-hosting means you produce and retain that evidence from your own logging and infrastructure. On Directus Cloud, request the vendor's audit documentation and any attestation it holds. DeployOpen prepares controls and evidence for your assessment but does not issue audit reports or certifications, and independent auditors decide what is sufficient.
Vendor data handling terms
For Directus Cloud, the data processing terms, subprocessors, breach notification window and data deletion on exit come from Directus, not from this comparison. Obtain the contract language directly from Directus before you select the managed option, and have your legal and privacy teams review it against your regulatory obligations. Self-hosting shifts these questions to your own subprocessor list and your own incident response plan.
Who qualifies to self-host Directus for free?
Self-hosting Directus for free is not open to every organization. Directus's pricing page says organizations with under 5 million US dollars in annual revenue and fewer than 50 employees qualify for free self-hosting with no feature limits under its Open Innovation Grant. Both conditions appear to apply together, so an organization above either threshold should not assume it qualifies. Check your most recent audited or management revenue figure and your current headcount against those numbers, and record the date you checked. Grant holders who want a managed instance can use Directus Cloud at 99 US dollars per month, which the pricing page lists as the grant holder rate.
The second test is the license, not the grant. 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. In plain terms, if your product or service competes with Directus Cloud or another paid Monospace offering, self-hosting may be restricted even when your size would otherwise fit the grant. Internal tools, customer-facing applications that are not a hosted Directus product, and agency work for clients each need a separate read. The license file in the directus/directus repository and the text at Directus license terms are the documents to review. Before you deploy, write down the facts that decide the question: revenue, headcount, what the Directus instance does for customers, and whether it could be read as a hosted database-API product. Send those facts to Directus in writing and ask for a confirmed answer on eligibility and Competing Use. For a binding interpretation of the license, have your counsel review the terms against your business model. Do not plan a rollout on the assumption that the grant applies until that confirmation is in hand.
What your team runs in each model
This table lists the operating tasks behind each deployment model and marks which ones Directus Cloud takes on and which stay with your team when you self-host with Docker. Read the rows as a checklist of who owns each task, then confirm the vendor boundary for Directus Cloud in writing before you decide.
| Operating task | Directus Cloud | Self-hosted Directus with Docker |
|---|---|---|
| Docker host and container updates | Vendor operates the hosting environment. Confirm the update process and maintenance windows with Directus. | Your team runs the Docker host, pulls new Directus images and restarts containers on your schedule. |
| SQL database provisioning | Vendor provisions the database behind the managed instance. Confirm which engines and versions are offered. | Your team creates and sizes an existing SQL database. Directus supports PostgreSQL, MySQL, MariaDB, Oracle, SQL Server, SQLite and CockroachDB through DB_CLIENT. |
| Backups and restore testing | Confirm backup frequency, retention and restore procedures in the service terms. Ask whether restore tests are performed and reported. | Your team designs backups of the SQL database and uploaded files, and tests restores in your own environment. |
| File storage for uploads | Confirm where uploaded assets are stored, how they are backed up and what is included in the plan. | Your team chooses and operates the storage backend for uploads, including capacity, access policy and backup. |
| TLS certificates and domains | Confirm who issues and renews certificates for custom domains on the managed service. | Your team issues, installs and renews TLS certificates at the reverse proxy or load balancer in front of the container. |
| Monitoring and alerting | Confirm which health, performance and log data the service exposes to you. | Your team selects and runs monitoring for the host, containers, database and application, and sets alert thresholds. |
| Version upgrades | Vendor applies platform upgrades on the managed service. Confirm timing and any changes you must test in your own content models. | Your team plans and tests each release, such as 12.4.0 (September 22, 2026) and 12.5.0 (October 7, 2026), before applying it to production. |
| Access administration | Your team manages Directus users, roles and permissions in Studio. Confirm which SSO and seat features your plan includes. | Your team manages Directus users, roles and permissions in Studio, plus the identity integration and the database accounts it uses. |
How to move between self-hosted Directus and Directus Cloud
This sequence gives you a tested path for moving a Directus project in either direction, with the data, files, access rules and API consumers verified on the target before you switch traffic and retire the source.
Confirm the migration path and database engine
Before any export, ask Directus in writing whether it supports the move you have in mind, from self-hosted to Directus Cloud or back, and which SQL engine and version the target environment accepts. Directus connects to PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB through the DB_CLIENT setting, so check that your current engine is on that list and that the hosted target matches it. Done when you hold a written answer on the supported path and a short note of the engine, version and any custom configuration you depend on.
Inventory schema, extensions and integrations
Your team, with the Directus administrator and any developer who built custom code, lists every collection, field, relation, role, permission, flow, custom extension and external integration that touches the instance. Include the API consumers that read or write through REST or GraphQL, the MCP or AI Assistant usage if enabled, and any environment variables that carry secrets. This inventory is where most of the cost and effort in the move is decided, because the size of the schema, the number of extensions and the number of integrations drive the test scope. Done when the list is reviewed by the owner of each consumer and nothing is marked unknown.
Export schema and data from the SQL database
Take a consistent snapshot of the database that backs the instance, then export the schema and the content in a form the target can import. Run this against a copy or during a freeze window agreed with content owners so writes do not land between the schema and data exports. Record row counts per collection and checksums where your database tooling supports them. Done when the export completes without errors, the counts match the source, and the snapshot is stored in a location both teams can access.
Move file assets and storage configuration
Copy uploaded files from the source storage location to the target and confirm that the storage adapter settings, bucket names or paths, and access policies match what the target expects. Asset references in content are only useful if the files resolve at the same locations, so compare a sample of records against the files they point to. Confirm with Directus which storage options the target environment supports, since that depends on the deployment model. Done when a random sample of assets opens from the target and file counts reconcile with the source.
Reconcile roles, permissions, flows and extensions
Recreate or import roles, permission rules, flows and custom extensions on the target, then compare them line by line against the inventory from the second step. Test each role with a real account, because a permission that looks right in a spreadsheet can still expose or hide collections in practice. Check that AI features and the MCP server, if you use them, still run under the same role-based permissions on the target. Done when every role has a signed-off test result and every flow and extension runs on the target with the expected output.
Test API consumers and integrations against the target
Point a staging copy of each API consumer at the target and run the read and write paths your business depends on, including authentication, filters, relations and any webhook or flow triggers. Compare the responses with the source for the same requests, and log any difference in field names, response shapes or error codes. Ask the owner of each integration to sign off, because a consumer that works in staging can still fail on rate limits or network rules in production. Done when every consumer has a passing test record and its owner has approved the switch.
Cut over DNS, secrets and access
In a change window agreed with stakeholders, rotate the secrets that the target needs, update environment variables and tokens in each consumer, and change DNS or the load balancer to point at the target. Keep the source running in read-only mode for a defined rollback period that your team sets, and confirm that writes are no longer arriving at the source. Done when the public endpoints resolve to the target, the old credentials no longer work, and the monitoring dashboards show normal traffic on the new instance.
Retire the old instance and keep the evidence
After the rollback period ends without a reason to revert, archive the final export, the test records, the permission reconciliation and the change log, then shut down the source and delete its database, storage and secrets according to your retention policy. Remove the old DNS records and any scheduled jobs that pointed at the retired instance. Done when the source is confirmed off, the archive is stored where your auditors can find it, and the owner has recorded the cost and effort actually spent for the next migration decision.
Questions buyers ask before choosing a hosting model
How much does Directus Cloud cost per month?
Directus lists Directus Cloud as a 99 US dollars per month add-on to the Core and Team plans, and Enterprise cloud is priced individually. That add-on covers hosting on Directus's managed service, but it does not cover the rest of your program. Confirm with Directus which plan your seat count and features require, whether storage, bandwidth or backups have usage limits, and whether support tiers change the monthly figure. Those items are set on the pricing page and in your contract, so check them before comparing totals.
Can my organization self-host Directus for free?
It may, but the answer depends on your size and how you use the software. Directus's pricing page says organizations with under 5 million US dollars in annual revenue and fewer than 50 employees qualify for free self-hosting with no feature limits under its Open Innovation Grant. Organizations above those thresholds need a paid arrangement. Directus is licensed under the Monospace Sustainable Core License 1.0, which permits any use except a Competing Use against Monospace's paid offerings, so confirm with Directus or counsel how your use case is classified before you deploy.
What do we have to run ourselves if we self-host Directus?
Self-hosting means you operate the Docker deployment, the SQL database that Directus connects to through its DB_CLIENT setting, file storage, backups, TLS, secrets, monitoring and every upgrade. Directus supports PostgreSQL, MySQL, MariaDB, Oracle Database, Microsoft SQL Server, SQLite and CockroachDB, so the database choice is yours and must be supported by your own DBA team. The workload scales with your environment:
- A team with container and database operations experience and an existing backup process has a smaller gap to close.
- A team without those skills needs training or outside help before go-live.
- Air-gapped or strictly controlled networks add patching, image mirroring and approval steps.
Estimate effort from an inventory of these items in your own environment.
How long does it take to move from Directus Cloud to self-hosting?
The duration depends on data volume, schema complexity, the number of extensions and integrations, the database you choose, and how many environments must be validated before cutover. No fixed figure applies to every team, so ask for a timeline based on your own schema and content inventory. Plan for a rehearsal of the database export and import, verification of permissions and file storage, and a rollback path. Confirm with Directus how the export and any licensing changes affect your contract before you schedule the switch.
Can we run a self-hosted Directus deployment without outside help?
A capable platform team can, provided it has the skills listed above and time to test. Directus's documentation and README cover Docker deployment and database configuration, which gives your engineers a starting point. The risk lies in the operational details that are easy to miss, such as backup restore testing, upgrade sequencing, and access control for the admin interface. Assess these gaps honestly before committing, and decide whether a short internal pilot will reveal them.
When should we bring in an implementation partner for Directus?
Bring in a partner when internal capacity, compliance deadlines or security requirements exceed what your team can absorb. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, typically under a fixed scope agreed in writing before work starts. Ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope and your environment.
Can Directus Cloud meet our internal data location rules?
Confirm this with Directus before you commit, because the answer depends on where Directus Cloud hosts your data and what your rules require. Ask for the hosting regions available to your plan, the location of backups, and how support staff access your environment. If those answers do not meet your residency or sovereignty requirements, self-hosting in your own cloud account, data center or air-gapped network keeps data location under your control, though it shifts operational responsibility to you.
What to confirm with Directus before you commit
Treat the figures on this page as a starting point, not a contract. The published Directus pricing page lists Directus Cloud as a 99 US dollars per month add-on to the Core and Team plans and puts Enterprise cloud at custom pricing, but seat limits, collection limits and what each plan includes can change between releases. Before you commit, get the current limits for each plan in writing, confirm what Enterprise cloud terms cover, and ask which hosting regions and data processing commitments apply to your tenant. Ask the vendor to name the document that governs each answer, and keep it with your procurement file. This page does not guarantee any of these terms.
Next, pin down the operational boundary. On Directus Cloud, ask who runs backups, what the restore process is, how long point-in-time recovery reaches back, and who is responsible for the SQL database that holds your collections. On a self-hosted deployment, the database, the DB_CLIENT choice, the Docker image tag, object storage and upgrades all sit with your team. Confirm the service level terms in writing, including response targets, maintenance windows and remedies, because a published uptime figure alone does not tell you what happens when an incident runs long.
Finally, get a written view on license fit for your specific use. The Monospace Sustainable Core License 1.0 permits any use except a Competing Use against Monospace's paid offerings, so whether your product, service or internal platform falls inside that exception needs a decision by your legal counsel, not an assumption. Also confirm eligibility for free self-hosting under the Open Innovation Grant against your current revenue and headcount, because those thresholds decide whether the Directus Cloud add-on is an optional expense or your only paid route.
Which team profile fits each model
The scenarios below are illustrative, not drawn from named clients. Each one points to a leaning between Directus Cloud and self-hosted Directus, and names the condition that would move the decision, because the hosting choice usually depends on data location, team capacity and whether the organization qualifies for free self-hosting.
Regulated bank with residency rules
Illustrative: a bank must keep customer records in a named country and in accounts its own security team controls. Self-hosted Directus in the bank's cloud or data center is the usual leaning, with Directus connected to the bank's existing SQL database. Check whether the Directus Cloud region and provider terms meet the residency rule before ruling it out, and confirm the Monospace Sustainable Core License terms with legal, since a self-hosted deployment still runs under that license.
Small publisher with a lean team
Illustrative: a three-person editorial team with no database administrator wants editors working in Studio without running infrastructure. Directus Cloud is the likely leaning, since the $99 per month add-on covers hosting on the Core and Team plans. The condition that changes this is eligibility for free self-hosting: if the publisher qualifies under the Open Innovation Grant, a Docker host with a managed SQL database may cost less, but someone must still own backups and upgrades.
Agency running many client sites
Illustrative: an agency operates a separate Directus project for each client and must decide who pays for hosting and who controls each database. Self-hosting on the agency's own Docker estate keeps per-client data in client-approved databases and avoids a managed add-on per project. Ask whether the Core and Team plan seat and collection limits fit each client's content model, and price the per-project upgrade and backup work before choosing.
Company with an existing SQL platform team
Illustrative: an enterprise already runs PostgreSQL or SQL Server with a database team, backup tooling and monitoring. Self-hosted Directus fits because Directus connects to that existing database through the DB_CLIENT setting rather than creating a separate data store. The condition that changes the choice is team capacity: if the platform team cannot take on Directus container upgrades and schema change reviews, Directus Cloud shifts that work to the vendor at a recurring cost.
Team requiring air-gapped operation
Illustrative: a public-sector agency runs workloads on a network with no outbound internet access. Self-hosted Directus is the only workable leaning, because Directus Cloud depends on vendor-hosted infrastructure. Plan the container image mirror, the SQL database inside the enclave and the process for moving license-compliant releases in. Confirm with DeployOpen's scoping and with Directus which features, such as the embedded AI Assistant, need outside network access.
How DeployOpen plans, runs and supports self-hosted Directus
DeployOpen plans, implements, 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 Directus, that means working from your database, storage and identity requirements to decide whether Directus Cloud or a self-hosted Docker deployment fits your environment, then running that choice through to a documented handover.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which SQL database Directus will connect to, how it is hosted, and who operates it.
- We confirm your license position for Directus against your organization's size and the Monospace Sustainable Core License terms before design begins.
How we build
- We deploy Directus with Docker in your environment, configured against your existing database through the DB_CLIENT setting.
- We set up file storage, backups, role-based permissions and the collections and roles your teams need in Studio.
- We test API access, permission boundaries and the native MCP server and AI Assistant settings before anything goes live.
How we hand over
- Handover documentation covers the deployment, database connection, backup and restore steps, and upgrade procedure.
- We document the runbook for each Directus release you adopt, so your team knows what changes before it applies an upgrade.
- Your team receives a walkthrough of Studio administration, role management and the operational checks it needs to run.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Retainers can cover applying new Directus releases, reviewing database and storage changes, and re-testing permissions after updates.
- Ask for a written quote that separates one-time build work from recurring support, so cost drivers stay visible.
