For years, the answer to "what's the best self-hosted wiki?" was, more often than not, Wiki.js. With over 100 million downloads and nearly 29,000 GitHub stars, it occupied a rare position: feature-rich enough for enterprise teams, light enough to run on a Raspberry Pi, and modern in a way the older PHP wikis were not. It was the wiki that treated Git as a storage backend and Markdown as the source of truth.
But 2026 is a more complicated story. Wiki.js is AGPL-3.0 — a strong copyleft license with a network clause — and its architecture carries real technical debt: the GraphQL layer that powers every operation, including authentication and administration, runs on Apollo Server 2.x, which reached end-of-life in October 2023. The build still leans on a legacy OpenSSL flag. And the maintenance cadence has slowed markedly, with the long-promised 3.x rewrite still in beta and the stable line quiet since spring 2026.
This is a long, honest teardown of what Wiki.js actually is, how its plugin-style architecture works, why Git-backed storage is genuinely useful, what the AGPL license demands of you, the security and maintenance realities behind that EOL GraphQL server, and precisely where your content and your credentials land.
1. What Wiki.js Is
Wiki.js is a modern, lightweight, powerful wiki application built on Node.js, with a Vue.js frontend and a GraphQL API at its core. Created in 2017 by Nicolas Giard (Requarks), it was designed from the start to be modular: storage, authentication, search, and rendering are all pluggable. That ambition is both its strength — it supports an unusually wide range of backends — and the source of the technical debt we will examine.
The current stable line is 2.5.x (for example v2.5.314, released May 1, 2026). The long-awaited 3.x rewrite has been trickling out in beta builds — 3.0.0-beta.543 shipped September 6, 2026 — but every 3.x build carries an explicit warning that it is not for production. So in practical terms, "Wiki.js" in 2026 means "Wiki.js 2.5.x, with a beta 3.x on the horizon."
It is AGPL-3.0 licensed. That matters more than the star count, and we will spend real time on it, because the AGPL's network clause changes what you are allowed to do if you modify the software and offer it as a service.
2. The Architecture: Node, Vue, GraphQL
Wiki.js is a Node.js application (minimum Node 20 per the engines field) with a Vue.js frontend bundled via Webpack. Every operation — creating a page, managing users, configuring storage, handling authentication — travels through a single GraphQL endpoint powered by Apollo Server. There is no separate REST layer; the admin UI and the page editor both consume the same GraphQL API.
The dependency manifest reveals the scope: storage backends include local filesystem, Git (via chokidar file-watching), AWS S3, and Azure Blob; authentication uses Passport.js with explicit Keycloak support and room for more strategies; search supports Algolia, Azure Cognitive Search, and built-in database-backed options; content formats include Markdown (GitHub Flavored), AsciiDoc, and HTML-to-Markdown conversion; and there is a full ACME protocol stack for automated Let's Encrypt certificates.
For an operator, this means a single Node process (plus your chosen database) can do a lot. But it also means one process owns auth, admin, and content — and that process's GraphQL server is the thing we will scrutinize for security debt.
3. Git-Backed Storage — the Genuine Highlight
The feature that made Wiki.js distinctive is Git storage. You can point a wiki at a Git repository and have every page edit committed as a real Git commit. That means your documentation has genuine version control: history, diffs, blame, and the ability to clone the entire wiki as plain Markdown. For teams that already live in Git, this is a powerful fit — docs become reviewable via pull requests, and content survives even if the wiki instance dies, because the repo is the source of truth.
The Git backend watches the filesystem (via chokidar) and syncs changes both ways. You can host that repo on your own forge (GitLab, Gitea — both covered in this series — or Codeberg) and treat the wiki as a writeable front end to a repo you control. Combined with the Markdown-first content model, this is about as portable as documentation gets: no proprietary database format stands between you and your content.
The caveat: two-way Git sync adds operational complexity. Concurrent edits, merge conflicts, and auth to the remote repo all become things you manage. For a solo operator or a small team it is a clean win; for a large org with many simultaneous editors, the conflict-resolution story needs thought.
4. Multiple Database Backends
Unlike BookStack (which requires MySQL), Wiki.js supports PostgreSQL, MySQL, MariaDB, SQLite, and SQL Server. That flexibility lowers the barrier to fitting it into existing infrastructure. PostgreSQL is the best-tested path and the one most operators choose; SQLite is viable for tiny single-user instances but not for concurrent team use.
The trade here is surface area: more supported databases means more code paths to keep correct, and the project's own history shows that storage and search behaviors have shifted between versions. Pick PostgreSQL, pin the version, and don't chase the exotic backends unless you have a concrete reason.
5. Authentication: Passport, Keycloak, LDAP, SAML, OAuth
Wiki.js's authentication is Passport.js based, which gives it a broad strategy ecosystem. It has explicit Keycloak support and infrastructure for LDAP, SAML, OAuth, and generic SSO. For a self-hoster who runs an identity layer — Keycloak, Authelia, or Authentik (all covered in this series) — Wiki.js slots in as an OIDC or LDAP client and can enforce central credential policy.
This is where the architecture's single-GraphQL-endpoint design matters: login and admin both flow through that endpoint. So the security of your auth is tied directly to the security of the Apollo Server instance, which (see Section 9) is running end-of-life software in 2026. The integration options are excellent; the underlying server they run on is the concern.
6. Built-In ACME SSL Automation
One genuinely nice feature: Wiki.js ships a full ACME protocol stack (acme, @root/keypairs, @root/pem, @root/csr) for automated Let's Encrypt certificate management. You can have the wiki obtain and renew its own TLS certificates without standing up a separate Certbot or Caddy. For a self-hoster who wants the wiki on its own subdomain with real certificates and minimal fuss, this is a real convenience.
The flip side is that you are trusting the wiki process with certificate private keys and the ACME account. That is fine behind your reverse proxy (Caddy or Traefik, both covered here) for internal use; for a public instance, weigh whether you'd rather terminate TLS at the proxy and let the proxy handle ACME, keeping cert material out of the app process. Either way, the built-in option exists and works.
7. Search: Algolia, Azure, or Database-Backed
Wiki.js supports Algolia and Azure Cognitive Search as external engines, plus a built-in database-backed search. For a self-hoster who wants zero external dependencies, the database-backed search (PostgreSQL full-text, for example) keeps everything in-house. Algolia and Azure are options if you need scale or relevance features and are willing to hand data to those providers.
The honest take: for the scale most wikis actually reach (thousands of pages), the built-in search is adequate and keeps your content sovereign. Reach for Algolia only if you have a specific relevance or scale need and accept the third-party custody that comes with it.
8. Content Formats and Editor
Wiki.js supports Markdown with GitHub Flavored extensions, AsciiDoc, and HTML, with a Markdown editor and a WYSIWYG-style editor. Multi-language support covers 40+ interface languages, and there is a dark mode. Media management handles image and file uploads. Version history lets you roll back page changes.
Compared to BookStack's CKEditor WYSIWYG, Wiki.js leans Markdown-first, which engineers like and non-engineers tolerate less. The 3.x betas have been adding draw.io diagram blocks and public user profiles — features the 2.x line lacked — but those are beta-only as of late 2026.
9. The Elephant in the Room: Apollo Server 2.x Is End-of-Life
Here is the fact every serious operator should know before a production deployment. Wiki.js's package.json pins
apollo-server: 2.25.2 and
apollo-server-express: 2.25.2. Apollo Server 2 reached end-of-life in October 2023. In mid-2026, that means the GraphQL server handling
every operation in the application — including authentication and admin functions — has received no upstream security patches for nearly three years.
This is not a theoretical concern. The GraphQL endpoint is the front door to user management and permission changes. Running an EOL server in that role means any vulnerability discovered in Apollo Server 2.x after October 2023 has no upstream fix; the Wiki.js project would have to patch it themselves or wait for the 3.x rewrite. The maintainers are clearly aware — the open issue tracker has a v3 parity checklist, and several items are tagged [v3]. Until 3.x ships as stable, operators are running an EOL GraphQL server in a security-sensitive job.
The mitigation is blunt: keep Wiki.js behind your reverse proxy with WAF and rate-limiting, restrict admin network access, enforce MFA where the IdP provides it, and watch the 3.x stable release closely. But the structural risk is real and should be named, not buried.
10. The Build Workaround: OpenSSL-Legacy Provider
A second piece of technical debt shows up in the build scripts. Both the dev and build npm scripts set
NODE_OPTIONS=--openssl-legacy-provider. This flag forces Node.js to use legacy OpenSSL APIs that OpenSSL 3.x (shipped with Node 17+) removed — because some Webpack dependencies use the MD4 hash algorithm for asset fingerprinting, which OpenSSL 3.x dropped.
Since Wiki.js targets Node >= 20, this flag is a permanent workaround, not a temporary shim. It is a clear signal that the build toolchain has not been modernized to match the stated runtime. For an operator it is mostly invisible (you run the prebuilt image), but it tells you something about the project's modernization pace — and it is the kind of flag that can break on a future Node release that removes the legacy provider entirely.
11. The AGPL License — What It Actually Demands
Wiki.js is AGPL-3.0. The AGPL is a strong copyleft license with a network clause: if you modify the software and let users interact with it over a network (i.e., you run a modified version as a service), you must offer those users the corresponding source of your modifications. Unlike the plain GPL, the AGPL closes the "application service provider loophole" — merely running it as a network service does not escape the obligation to share changes.
For a normal self-hoster who runs Wiki.js unmodified, this changes nothing: you can use it freely, commercially or not. The obligations bite only if you (a) modify the source and (b) expose that modified version to users over a network. At that point you must publish your changes. For most internal documentation uses, you will never trigger this. But if your business plan is "fork Wiki.js, add features, and sell it as a hosted SaaS without releasing the fork," the AGPL blocks you — which is exactly the point of the license.
Contrast this with BookStack's MIT (Section 13 of the companion piece): MIT imposes no such network clause, so a modified BookStack could be offered as a closed service. If license freedom for a hypothetical SaaS wrapper matters to you, that difference is decisive.
12. The 2026 Maintenance Slowdown
The most important adoption question in 2026 is not features — it is momentum. Public health signals for Wiki.js have weakened. One tracker scored it 45/100 with 41 commits in the trailing twelve months, activity in only 8 of 12 months, and zero commits in the most recent quarter (last commit reported around May 1, 2026). Another source still shows active release history into mid-2026, but the cadence is thinner than the project's heyday.
The root cause is the 3.x rewrite. The maintainer has been pouring effort into a from-scratch rewrite (new frontend, new architecture) that has lived in beta for a long time. The stable 2.5.x line, meanwhile, gets fewer changes. For an operator this creates a real planning problem: do you deploy a stable-but-slowly-maintained 2.5.x, or bet on a 3.x that is explicitly not production-ready?
The prudent answer: deploy 2.5.x if you need it now, but factor the slowdown into your risk model (Section 14), and keep a clean exit path (the Git backend makes this easy). Do not adopt 3.x beta for anything you care about.
13. Bus Factor and Project Governance
Wiki.js is fundamentally a one-maintainer project (Nicolas Giard / Requarks), with community contributors around it. Like BookStack, this concentrates the project's future on one person's continuity. The difference is that Wiki.js's single maintainer is also locked in a multi-year rewrite, which divides attention between keeping 2.5.x alive and finishing 3.x.
This is not a verdict that the project is dead — 100M+ downloads and a large installed base mean it will keep running for years regardless. But "the person who maintains it is deep in a rewrite" is a fact that should shape how much you build on top of it. The AGPL at least guarantees you can fork and self-maintain if you must; the bus factor is why you might one day need to.
14. Where Your Data Goes
Precisely, when you self-host Wiki.js:
- Content lives in your chosen database (PostgreSQL recommended) and, if you enable Git storage, is also committed to your Git repository. That repo is the strongest portability guarantee in the whole stack.
- Authentication via OIDC/SAML/LDAP is brokered by your own IdP. Wiki.js does not phone home for login.
- Search with the built-in engine stays in your DB. If you choose Algolia or Azure Cognitive Search, those providers receive indexed content — a custody choice you make explicitly.
- TLS with built-in ACME means cert material lives in the wiki process; behind a proxy, the proxy holds it instead.
- Telemetry: the core does not ship a mandatory phone-home beacon. There is no commercial entity harvesting usage.
The one structural caveat is the GraphQL endpoint (Section 9): because it handles auth and admin, its EOL server is the weakest link in the data-security chain. Mitigate with proxy hardening and network restrictions.
15. Wiki.js vs BookStack
These two are the serious self-hosted wiki contenders, and the contrast is sharp:
- License: Wiki.js is AGPL-3.0 (network clause); BookStack is MIT (no clause). If a future SaaS fork matters, BookStack wins on freedom.
- Storage: Wiki.js offers Git-backed Markdown as a first-class backend; BookStack stores in MySQL with no native Git. If "docs as code" is a hard requirement, Wiki.js wins.
- Editor: BookStack's CKEditor WYSIWYG is friendlier to non-engineers; Wiki.js is Markdown-first.
- Maintenance (2026): BookStack ships monthly security releases and is actively developed; Wiki.js's stable line is slowing while 3.x beta drags on. BookStack wins on current momentum.
- Runtime: BookStack is PHP/MySQL (familiar, low-surprise); Wiki.js is Node with an EOL GraphQL server and a legacy OpenSSL build flag (more debt).
Pick Wiki.js if Git-backed docs and Markdown are central and you accept AGPL plus maintenance risk. Pick BookStack if you want MIT comfort, active maintenance, and a WYSIWYG your whole team will use.
16. Deployment and Operations
Wiki.js runs as a Node process plus your database. The official Docker image bundles the app; you supply PostgreSQL (or another supported DB) and a storage target. Behind a reverse proxy (Caddy or Traefik), you terminate TLS and forward to the container. Resource needs are modest — 1–2 GB RAM and a couple of CPU cores is comfortable for a team.
Upgrades on 2.5.x are generally smooth within the line, but the project warns that 3.x will be a different architecture; treat any 2.x-to-3.x move as a migration, not a patch. Back up the database (and your Git repo, if used) before every upgrade. Because content can live in Git, your rollback story is stronger than most: even a broken upgrade rarely loses content if the repo is current.
17. Backup and Disaster Recovery
The Git-backend option makes backup almost trivial: clone the repo offsite on a schedule and you have the entire wiki as Markdown. Without Git storage, back up the PostgreSQL database (or your chosen backend) and the uploaded-files volume. The built-in DB search index is derived, so a restore may need a re-index — the same caveat as BookStack.
The discipline is the same as everywhere: a dump to the same disk is not a backup. Ship it offsite. The Git backend's great virtue is that "offsite backup" can be "push to a repo you already trust," which lowers the friction of doing it right.
18. Security Hardening Checklist
Given the EOL GraphQL server, harden deliberately:
- Put Wiki.js behind your reverse proxy; do not expose the Node port directly.
- Enable WAF and rate-limiting at the proxy.
- Restrict admin routes to a trusted network or VPN where possible.
- Enforce MFA at your IdP (Keycloak/Authelia) since the app's own auth path is the weak link.
- Keep the instance patched; watch the 3.x stable release for the Apollo Server upgrade.
- Disable public registration on private instances; use invite or SSO-only.
- If using built-in ACME, secure the cert store; prefer proxy-terminated TLS for public exposure.
None of this is exotic — it is standard web-app hardening, applied with extra care because of the EOL dependency underneath.
19. Who Should Run It — and Who Shouldn't
Run Wiki.js if: you want Git-backed Markdown documentation with real version control; you are comfortable with Node and PostgreSQL; you accept the AGPL and have no plan to ship a modified network service; and you can live with a slowing stable-line cadence while 3.x matures.
Do not run Wiki.js if: you need a vigorously maintained security posture today (the EOL GraphQL server is a hard stop for some); you want a WYSIWYG-first editor for non-engineers (BookStack fits better); or you require vendor SLA support (there is no commercial backer). If AGPL freedom for a hypothetical SaaS wrapper is a blocker, look at BookStack or DokuWiki instead.
20. The Verdict
Wiki.js is a capable, genuinely portable wiki with a standout Git-backed storage model and a permissive-enough AGPL for ordinary self-hosting. But in 2026 the honest rating has to weigh the architecture's debt: an end-of-life GraphQL server in the auth path, a legacy OpenSSL build flag, and a maintenance cadence throttled by a years-long rewrite. None of that makes it unsafe to run behind a hardened proxy for internal docs — but it does mean you adopt it with eyes open, keep a clean Git-based exit path, and watch the 3.x stable release as the moment the debt gets paid down.
For a sovereign operator who values portable, Git-native docs and can accept copyleft plus maintenance risk, Wiki.js remains a serious choice. Just don't mistake its download count for a maintenance guarantee.
21. A Practical Install Walkthrough
The lowest-friction path is the official Docker image plus a PostgreSQL container, behind your reverse proxy. A minimal shape:
``
yaml
services:
db:
image: postgres:16
environment:
POSTGRES_DB: wikijs
POSTGRES_USER: wikijs
POSTGRES_PASSWORD: change-me
volumes:
- wikijs_db:/var/lib/postgresql/data
wiki:
image: requarks/wiki:2.5
depends_on: [db]
environment:
DB_TYPE: postgres
DB_HOST: db
DB_PORT: 5432
DB_NAME: wikijs
DB_USER: wikijs
DB_PASS: change-me
ports:
- "3000:3000"
`
Bring it up, complete the setup wizard at port 3000, then put Caddy or Traefik in front to terminate TLS and restrict admin access. The wizard asks for the database connection, a site URL, and an admin account. Use a strong admin password or, better, disable local admin login once SSO is wired (Section 23). Back up the wikijs_db
volume and, if you enable Git storage, your remote repo.
22. Configuring Git Storage Step by Step
Git-backed storage is the feature most worth setting up. In the admin panel, go to Storage, add a Git backend, and provide:
- A repository URL (your own Gitea, GitLab, or Codeberg repo).
- An authentication method — SSH key or HTTPS token. Use a deploy key scoped to that repo, not a personal account.
- A branch and a commit author identity.
- Sync direction: two-way (wiki commits edits, and external commits pull in).
Once enabled, every page save becomes a commit with the editor's identity. This gives you real history and a portable copy. The operational care points: SSH keys must be mounted into the container and permissioned correctly; the wiki needs push access to the remote; and concurrent edits from both the UI and Git can produce merge conflicts that you resolve in the repo. For a solo or small team, two-way sync is a clean win. For a large org, consider one-way (wiki → repo) as a publish mirror to avoid conflict churn.
23. Wiring SSO with Keycloak
Because the app's own auth path runs an EOL server, brokering login through your IdP is the right move. In Wiki.js, add an authentication strategy of type OIDC or SAML and point it at your Keycloak (or Authelia) realm. Map the email
and name` claims, set the redirect URI exactly as Keycloak shows, and restrict the strategy to your domain. After testing, you can disable local password login for non-admin users so all interactive auth flows through the IdP — which means the weak link (the app's GraphQL auth) is only exercised by the IdP's tokens, not by raw password handling.
The common failure is a redirect-URI mismatch or a missing claim mapping; both surface as a login loop. Check the exact callback URL in Wiki.js's auth settings and replicate it in the IdP client. Once SSO works, enroll MFA at the IdP so the wiki inherits it without the wiki implementing anything.
24. The 3.x Rewrite: What's Actually Changing
The 3.x line is a from-scratch rewrite, not a incremental update. Public betas through late 2026 (3.0.0-beta.543 and friends) have added draw.io diagram blocks, public user profiles, folder and asset management operations, and incremental UI parity with 2.x. Under the hood the architecture is being reworked. The maintainer's stated goal is to clear the technical debt — including, presumably, the Apollo Server 2.x situation — and reach a modern, maintainable core.
The catch is time. The rewrite has lived in beta for a long stretch, and the stable 2.5.x line has slowed as attention moved to 3.x. For an operator, the practical reading is: 3.x is the future, but it is not safe to run today. Deploy 2.5.x now, keep your Git-backed content portable, and treat the 3.x stable release as the event that lets you upgrade into a debt-free architecture. Do not adopt beta for anything you care about.
25. Performance and Scaling Notes
Wiki.js is light. A team wiki runs comfortably on 1–2 GB RAM and a couple of CPU cores. The database is the main stateful component; size it for your content volume, which for docs is modest. Search with the built-in engine stays in the DB and scales with your page count rather than your traffic.
Scaling notes that matter: the single Node process is the unit of compute; for high concurrency you can run multiple app containers behind the proxy against a shared database, but the GraphQL endpoint remains the shared bottleneck. For very large wikis (tens of thousands of pages), the built-in search may need the Algolia or Azure backend for relevance — at the cost of sending indexed content to those providers. For the typical self-hosted case, PostgreSQL full-text is enough.
26. Common Failure Modes
Login loop after enabling SSO. Redirect-URI mismatch or missing claim mapping (Section 23). Fix in the IdP client.
Search empty after restore. The search index is derived; re-index from the admin panel or CLI after a DB restore.
Broken assets after upgrade. The OpenSSL-legacy build flag (Section 10) can bite on a Node version that drops the legacy provider. Pin your Node image to a version known to work with 2.5.x.
Git sync stops. Usually an expired deploy key or lost push permission. Check the container's mounted key and the remote repo's access rules.
High memory on large imports. Bulk imports via API can spike memory; throttle batch size and watch the container limits.
27. The Self-Hosted Wiki Landscape
Wiki.js does not compete alone. The realistic field:
- BookStack (MIT, PHP/MySQL, WYSIWYG, active): simpler, more permissive, but no Git backend.
- Outline (BUSL-licensed, needs more infra): slick and API-driven, but not OSI-open and heavier to run.
- Docmost (AGPL-3.0, collaborative): a younger Confluence alternative with real-time collab, actively maintained.
- DokuWiki (GPL-2.0, flat files, no DB): ultra-light and durable, but dated UI.
- Gollum (MIT, Git-backed, single-user lean): great as a personal Git wiki, not a team platform.
Wiki.js's differentiators are Git-backed Markdown, broad backend support, and a modern UI. Its drags are the AGPL network clause, the EOL GraphQL server, and 2026's maintenance slowdown. Pick by which column you weight most.
28. The Sovereignty Scorecard
- Data ownership: 9/10. Git-backed storage makes content portable and externally safe; the DB is yours.
- License freedom: 7/10. AGPL is fine for unmodified self-hosting but constrains a modified network service.
- Operational cost: 7/10. Node + Postgres is standard; the legacy build flag and EOL server add care.
- Lock-in risk: 3/10. Git + Markdown exit is excellent; you can leave cleanly.
- Maintenance risk: 5/10. Slowing stable line and a multi-year rewrite are the dent; large install base cushions abrupt death.
Net: a strong yes for Git-native docs teams who accept copyleft and current maintenance reality, with the explicit plan to track 3.x stable as the debt-clearing upgrade.
29. FAQ
"Is Wiki.js dead?" No. Downloads and install base are huge, but the stable-line cadence has slowed in 2026 while 3.x beta continues. Plan accordingly.
"Can I use it commercially?" Yes — AGPL allows commercial use. You only must release modifications if you offer a modified version as a network service.
"Is 3.x safe for production?" The project says no; it is beta. Run 2.5.x.
"Why does it need the OpenSSL-legacy flag?" Webpack deps use MD4 hashing removed in OpenSSL 3.x; the flag is a permanent workaround on Node 20.
"Should I worry about Apollo Server 2 EOL?" Yes, for security posture. Mitigate with proxy hardening, MFA at your IdP, and network-restricted admin.
30. Real-World Deployment Scenarios
Three shapes where Wiki.js earns its keep:
- Engineering team knowledge base. Git-backed Markdown means runbooks and architecture notes live in a repo your CI and other tools can read. Engineers adopt it because the content is plain files, not a walled garden. Pair with Keycloak SSO and per-group page permissions.
- Product documentation site. Markdown-first authoring and multi-language support suit a docs portal. Use the built-in DB search for a small public site, or Algolia if relevance at scale matters and you accept the custody trade. Behind Caddy with ACME offloaded to the proxy.
- Internal policy manuals. Role-based page permissions and SAML/LDAP via your IdP keep HR and security docs locked to the right groups. The WYSIWYG helps non-engineers contribute, though it is less polished than BookStack's.
In each case the same guardrails apply: proxy-hardened, SSO-brokered auth, Git-backed content for portability, and offsite backups of both the DB and the repo.
31. Migrating from Confluence or Notion
If you are leaving a SaaS wiki, Wiki.js's Markdown model helps. Export source content to Markdown (both Confluence and Notion offer Markdown export, with varying fidelity on tables and embeds), then import via the REST API or by committing directly to the Git storage repo. The API path preserves revisions and permissions; the Git path preserves portable history.
Map the old hierarchy to Wiki.js's flat page-plus-tag model rather than forcing deep nesting — Wiki.js is less strictly hierarchical than BookStack, so lean on tags and the sidebar for structure. Validate formatting after import: tables, callouts, and code blocks are the usual casualties of a Markdown round-trip. Budget a cleanup pass. As with any migration, stage one space first, confirm the team can find and edit content, then move the rest. The Git backend means even a messy import is recoverable, because every commit is a checkpoint.
32. A Note on the 100M Downloads
Wiki.js's download count is often cited as proof of health, and it is real — a huge installed base means the software works and will keep running on machines worldwide for years. But downloads measure past adoption, not future maintenance. A project can be both wildly successful and quietly slowing, and 2026 Wiki.js is exactly that case: beloved, deployed, and in the long tail of a rewrite. Read the count as "safe to keep running what I have," not as "safe to build new critical dependencies on without a plan." The AGPL gives you the fork-and-own escape hatch if the slowdown ever becomes a stop; the Git backend gives you the walk-away escape hatch if you simply outgrow it. Both are reasons the download count still matters — just not in the way the marketing framing implies. For a sovereign operator, that combination of portability and forkability is the real insurance policy. Run 2.5.x today, track 3.x for the debt payoff, and keep your repo current — that is the whole playbook.
Related
For the rest of a sovereign, self-hosted stack, these pieces from our series travel with Wiki.js:
Comments (0)
No comments yet. Be the first to comment!