“Free to self-host” is the phrase that sells this decision, and it is the phrase that misleads it.
The licence fee is the smallest number in the comparison, and it is the only one anybody puts on the page. The real question is not what the software costs. It is who is responsible when it stops working, and what that responsibility costs in attention, at a time you did not choose.
That reframing changes the answer for a lot of teams, and it is the honest version of a question the category answers with a pricing table.
The two things “self-hosted” actually means
The word covers two very different arrangements, and mixing them up is why so many teams get this wrong.
Self-hosted, self-operated. You run the software on infrastructure you rent or own. You handle updates, backups, security patches, scaling, monitoring, and the incident at 2am. Directus’s own documentation describes this arrangement plainly: you can “Run Directus on your own infrastructure with Docker or your platform of choice” (Directus Docs, read 2026-08-28).
Self-hosted, someone-else-operated. The software is the same open-source product, and a hosting company or an agency runs it for you. You pay for that, and the payment is the point: you are buying the on-call rota, not the software.
The second arrangement is much more common than the marketing on either side suggests, and it is often the correct answer. It is also the one that gets lost when the comparison is framed as “free versus paid”.
What you actually take on
If you self-operate, this is the list. It is not long, and every item on it is a thing that will eventually happen at an inconvenient moment.
Updates. Security patches arrive on a schedule set by other people. Skipping them is how a content site becomes an incident.
Backups, and restores. Everybody has backups. Far fewer have ever performed a restore, which is the only thing that establishes whether the backups work. This is the same discipline this site applies to migration: backing up before a CMS migration covers what a verified backup actually means, and it applies to steady-state operation as much as to a move.
Monitoring. Knowing the site is down before your readers tell you.
Scale. Traffic that arrives faster than the machine you sized for it.
Someone who knows how. The most under-counted item, and the one that changes when a person leaves.
If you are cloud-hosted, the vendor takes all five and you take a different list: their maintenance windows, their incident response times, their decisions about the product, and their pricing.
The question that actually decides it
Not “can we run this”. Most technically capable teams can.
“Who is the second person?”
Every self-operated arrangement has a single point of failure, and it is usually a person rather than a machine. One developer set it up. One developer knows the deploy process. One developer’s laptop has the credentials.
That arrangement works perfectly until that person is on holiday, ill, or has left, and it fails at exactly the moment nobody can help. If you cannot name a second person who could handle a 2am incident, you do not have a self-hosted setup. You have a dependency on an individual.
This is the same shape as the risk covered in what happens if the vendor shuts down or gets acquired, pointed inward: in one case you depend on a company, in the other on a person, and the second dependency is usually the more fragile.
What cloud hosting is actually buying
Stated plainly, because the vendor pages describe features rather than the thing you are paying for.
You are buying someone else’s on-call rota, someone else’s patching schedule, and someone else’s problem when a dependency has a security advisory. That is a real service and it is worth real money, and framing it as “the paid option” undersells what it does.
You are also buying constraints. Their update timing, their feature roadmap, their extension model, their limits, and their pricing changes.
The trade is not cost against freedom. It is attention against control.
Costs that appear on neither page
Some of what makes this decision expensive is not on any comparison table.
Attention is a cost. An hour spent on a certificate renewal is an hour not spent on content, and on a small team that trade is the whole business.
Interruption is a cost with a multiplier. Being paged during a launch, a holiday, or a Friday evening costs more than the same work would cost on a Tuesday morning.
Knowledge is a cost that compounds. Every custom operational arrangement is something a future person has to learn, and the cost of that is paid at the worst possible time.
The costs that appear later rather than at signup are a subject in their own right, and they behave the same way on both sides of this decision.
How to decide, in five questions
Answer these honestly rather than aspirationally.
1. Who is the second person? If you cannot name them, cloud or managed hosting.
2. What actually happens if the site is down for four hours on a Sunday? For some publications that is an inconvenience. For others it is revenue. The answer changes the arrangement you can accept.
3. Is there a requirement that forces self-hosting? Data residency, a regulatory constraint, an integration that must run inside your network. If yes, the decision is made and the question becomes who operates it.
4. Is your team’s technical capacity real, or is it one person’s enthusiasm? These look identical in a planning meeting and completely different six months later.
5. What do you actually want to spend your attention on? This is the honest version of the whole question, and for a content team the answer is usually content.
For most small content teams, the answer that falls out of those five is the same one this site’s pillar reaches on the broader question: how to choose a CMS without reading 165 vendor pages argues that for many teams the right platform is the one they already have, and the same reasoning applies to hosting.
The middle options nobody frames as options
The decision is usually presented as binary and it is not.
Managed hosting for an open-source platform. You keep the software and the portability; someone else keeps the pager. This is the option that suits the most teams and gets the least attention, because neither side of the marketing has a reason to describe it.
Cloud now, self-hosted later. If the platform is genuinely portable, starting managed and moving later is a real path. Whether it is genuinely portable is the question, and it is answered by whether you can get your content out, which is what exporting your content from a CMS is about.
An agency retainer. Someone else’s second person, on a contract.
Before you choose either
One thing to establish regardless of which way you go: can you leave?
The self-hosted answer to that is usually better, and it is not automatic. Owning the server does not mean owning a usable copy of your content in a form another system can read. Run the export test before you commit, not when you want to leave, and what actually breaks during a CMS migration covers what the export is likely to lose.
The short version
- The licence fee is the smallest number in this decision.
- “Self-hosted” covers self-operated and someone-else-operated. They are different products.
- Self-operating means updates, verified restores, monitoring, scale and a person who knows how.
- The deciding question is who the second person is. If you cannot name them, you do not have a self-hosted setup.
- Cloud buys someone else’s on-call rota and sells you their constraints.
- Managed hosting for open-source software is the option nobody markets and it suits most small teams.
- Whichever you pick, establish that you can get your content out first.
