Self-hosted vs cloud wiki: how to actually choose

TL;DR. Self-host a wiki when you are required to keep data on your own infrastructure: air-gap, strict data-residency, regulated environments. Otherwise, cloud usually wins, because the work nobody budgets for is the maintenance, and a cloud wiki does that work for you. The whole debate is really one fear in a trench coat: lock-in. A clean Markdown export settles it. We’ll name real options on both sides and tell you plainly where we don’t fit.

Choosing between a self-hosted and a cloud wiki is mostly a question about who you want doing the unglamorous work. The honest answer: pick a self-hosted wiki when you are mandated to keep data on your own servers, and pick a cloud wiki when you are not. Most teams are not mandated, talk themselves into self-hosting anyway for the feeling of control, and discover the feeling has a maintenance schedule attached. (Control is a wonderful feeling right up until the security patch lands on a Friday.)

This post is written by a cloud wiki, so read it with the appropriate amount of salt. We are going to be even-handed anyway, because the self-hosted vs cloud wiki question has a real answer for each side and we’d rather you land on the right one than the one that pays us.

What the two models actually are

A self-hosted wiki runs on infrastructure you control — your own server, your own backups, your own upgrade schedule. The software is often open-source and free to download. You install it, you run it, you own everything that goes wrong at 2 a.m.

A cloud wiki runs on the vendor’s infrastructure. You sign in, you write, and the parts you never see — patching, backups, scaling, uptime — are the vendor’s full-time job. You pay per user instead of per server-plus-the-person-who-tends-it.

That’s the whole split. Everything else in the self-hosted vs cloud wiki debate is a consequence of who owns the maintenance. For the wider category these both sit inside, our knowledge base software shortlist walks the field tool by tool.

The comparison table

The table everyone actually came for. Honest cells, no thumb on the scale.

Dimension	Self-hosted wiki	Cloud wiki
Control / data residency	Full. Data lives on infrastructure you own. The win that justifies the rest.	The vendor’s infrastructure under their model. Residency depends on their regions.
Maintenance burden	Yours. Installs, upgrades, backups, server tending — all on your team.	The vendor’s. You log in; they keep the lights on.
Cost shape	Low or zero licence; real cost is the server plus the ops time nobody budgets.	Flat per-user price. The ops cost is folded in and predictable.
Speed	Depends entirely on your hardware and tuning. Can be fast; often isn’t.	The vendor’s responsibility. Raccoon Page: sub-second loads, keyboard-first.
Security patching	Yours to apply, on your schedule, which is the schedule that slips.	Patched by a team whose only job is patching. Usually faster than a small team manages.
Compliance	You build and audit it. GDPR, SOC 2, encryption — all on you.	Handled by the vendor. Raccoon Page is GDPR- and CCPA-compliant, encrypted in transit and at rest.

The pattern in the table is the pattern in real life: self-hosting trades money-and-time for control, and cloud trades control for money-and-time-back. Neither is a free lunch. Pick the lunch that matches your constraints.

The real self-hosted options

These are real, maintained projects. If you’re going to self-host, self-host one of these, not a fork someone abandoned in 2019.

BookStack. The common default for documentation-shaped wikis. Books, chapters, pages; clean, simple, easy to stand up. If you want a self-hosted wiki and don’t have a strong opinion yet, this is the one most people land on.
DokuWiki. Plain files, no database. The lightweight, low- resource option that reads its own data outside the wiki because it’s just text files on disk. Beloved by people who distrust databases on principle.
Wiki.js. The modern one — Node.js, Git-backed, Markdown, a visual editor. If you want a self-hosted wiki that doesn’t look like it was designed in 2008, Wiki.js is the usual pick.
Outline. An open, polished team wiki you can self-host. Closer in feel to a modern cloud product than the older options, with the trade-off that running it is a real deployment, not a single PHP file.
MediaWiki. The heavyweight that runs Wikipedia. Enormous, powerful, and more wiki than most ten-person teams will ever need. Reach for it when you genuinely have Wikipedia’s problems.

The honest read across all of them: the software is good. The work isn’t the software. The work is the server the software runs on, and that work doesn’t show up in any feature comparison.

The real cloud options

The other side of the table, named factually.

Confluence Cloud. Atlassian’s hosted wiki, the corporate default since 2004, strongest when your team is already on Jira. Our what is Confluence explainer covers it in depth. Slower than the modern options on a typical workspace; the incumbent for a reason.
Notion. The flexible cloud workspace where the database-as-doc abstraction lets a small team move fast — and becomes a discovery problem somewhere around the fortieth page, when nobody can find anything.
Raccoon Page. Cloud-only, keyboard-first, built for small technical teams. Sub-second loads. Keyboard-first. The rest of this post is honest about where we fit and where we don’t, so keep reading before you take that as a pitch.

An honest note: Raccoon Page is cloud-only

This is the section the rest of the post is built to earn, so here it is without decoration.

Raccoon Page has no self-hosted edition. It is cloud-only SaaS. There is no on-premise build, no air-gapped install, no download-and-run-it-yourself option, and we have no plans to ship one. If your organisation is mandated to keep wiki data on its own infrastructure — an air-gapped network, a strict data-residency rule, a regulated or classified environment, an internal policy that forbids third-party hosting — then Raccoon Page is the wrong tool, and you should pick a self-hosted option from the list above. BookStack, DokuWiki, Wiki.js, and Outline are all real answers to a real constraint. We are not one of them. Telling you that plainly is more useful than pretending we bend to fit a requirement we don’t meet.

So who is cloud actually for? The team without a spare ops person. The case for a cloud wiki, where it genuinely wins:

No ops burden. Nobody on your team upgrades a server, restores a backup, or owns the 2 a.m. page. That work exists either way; cloud is the model where it isn’t yours.
Speed handled for you. Sub-second loads are our problem, not your hardware’s. Pages load in 50-150ms depending on your network, and the keyboard does the rest — 30+ shortcuts, a command palette, slash commands, on every plan.
Security patching as a full-time job. A vulnerability lands; we patch it. It is our entire job, not a task someone on your team gets to on a quiet Friday that never arrives.
Compliance handled. GDPR- and CCPA-compliant from day one, encrypted in transit and at rest, we never train AI models on your content, and we never sell your data. You inherit that posture instead of building it.

If none of those is worth giving up control over your infrastructure, self-host. If all of them are, that’s what cloud buys.

The lock-in fear, and the thing that settles it

Here’s the opinion this post stands behind, and it’s the one most self-hosted vs cloud wiki arguments dance around: most teams who self-host are buying insurance against vendor lock-in, and a clean export is a cheaper policy. The fear is real — nobody wants their knowledge base held hostage by a vendor who changes the pricing or disappears. Self-hosting answers that fear by owning the server. But owning the server is an expensive way to own your data, and the data is the part you actually care about.

The cheaper policy is portability. Raccoon Page exports everything as Obsidian-compatible Markdown — frontmatter preserved, attachments included — on every plan, including the free one. That’s the per-space zip export: your whole wiki, as a folder of plain Markdown files, whenever you want it, no sales call. If you can walk out the door with all your content in a standard format any tool can read, the vendor doesn’t have you locked in. The lock-in fear that drives a lot of self-hosting decisions mostly evaporates once the export is clean.

We dogfood this, which is the only reason we get to claim it. Raccoon Corp — our own fictional-but-functional company — runs its internal wiki on Raccoon Page, including five public spaces anyone can browse without signing up. The export is the same one you’d use. (Bandit, our CTO, insists the export is “quantum.” It is a zip file. The name stuck.)

How to actually decide

The decision tree, briefly, because you’ve read enough.

Self-host if:

You are mandated to keep data on your own infrastructure (air-gap, data-residency, regulated, classified, or policy).
You have an ops person or team who will actually own the server, the backups, and the patch schedule.
Control over the infrastructure is worth more to you than the time it costs.

Go cloud if:

You have no mandate forcing data on-premise.
You don’t have a spare ops person, and you don’t want to become one.
You want speed, patching, and compliance to be someone else’s full-time job.
Your real worry is lock-in, and a clean Markdown export answers it.

The signal we’d watch above all the rest: who on your team is going to run the server? If the answer is a confident name, self-hosting is viable. If the answer is “we’ll figure it out,” you’ve just described the maintenance burden that sinks most self-hosted wikis — not because the software failed, but because the upgrade that needed doing kept not getting done.

Things people actually ask

Is a self-hosted wiki cheaper than a cloud wiki? Sometimes, but rarely once you count the ops time. The licence may be free, but you pay for a server, backups, upgrades, security patching, and the person who does all of that. Cloud wikis fold those costs into a per-user price. For a small team without a spare ops person, cloud is usually cheaper in total even when the sticker price is higher.

What are the best self-hosted wiki options? BookStack is the common default for documentation-shaped wikis. DokuWiki is the lightweight, no-database, plain-files option. Wiki.js is the modern Node.js choice with a visual editor. Outline is an open, polished team wiki you can self-host. MediaWiki is the heavyweight that runs Wikipedia. All are real, maintained projects with their own trade-offs.

When does self-hosting a wiki actually make sense? When you are mandated to keep data on your own infrastructure: air-gapped networks, strict data-residency rules, classified or regulated environments, or an in-house policy that forbids third-party hosting. If you have those constraints and a team to run the server, self-host. If you do not, you are usually buying ops burden you did not need.

Is a cloud wiki secure? A reputable cloud wiki patches faster than most small teams can, because patching is their full-time job, not a thing someone gets to on a quiet Friday. Cloud also handles compliance certifications, encryption in transit and at rest, and uptime monitoring. The trade-off is that your data lives on someone else’s infrastructure under their security model, not yours.

Does a cloud wiki mean vendor lock-in? Only if the export is bad. The real lock-in test is simple: can you get all your content out in a standard format on demand? Raccoon Page exports everything as Obsidian-compatible Markdown, with frontmatter and attachments, on every plan. If the export is clean, the lock-in fear that drives a lot of self-hosting decisions mostly goes away.

Is Raccoon Page self-hosted or cloud? Raccoon Page is cloud-only. There is no self-hosted or on-premise edition. If your organisation requires on-premise hosting, pick a self-hosted option like BookStack, DokuWiki, Wiki.js, or Outline instead. If you can use a hosted wiki, the cloud model is what lets us handle the ops, the patching, and the speed for you.

Can I move from a self-hosted wiki to a cloud wiki later? Usually yes, if both sides speak Markdown. Most self-hosted wikis export Markdown or a structured format an importer can read. Cloud wikis with import tooling consume it. The hard part is rarely the file conversion. The hard part is the team agreement to move and the time to clean up what you are bringing across.

What is the difference between on-premise and self-hosted? In practice they overlap. On-premise usually means hardware you own in your own building. Self-hosted is broader: your own server anywhere, including a VPS you rent in a data centre. Both mean you run the software and own the maintenance, as opposed to cloud, where the vendor runs it and you log in.

Self-hosted vs cloud wiki comes down to one question with no universal answer: who runs the server? If the answer has to be your own people, the self-hosted field is good and you should pick from it. If the answer is “ideally nobody we have to hire,” that’s cloud, and the lock-in fear that made you hesitate is answered by an export, not a server room. Raccoon Page Free is three users, one space, a hundred pages, no card — enough to find out whether not-running-the-server suits you. The comparison of wiki software on Wikipedia is the long version if you want to browse the whole field first. Worst case, you export the lot as Markdown and walk. We built the door on purpose.