Wiki.js Setup Guide: Build a Wiki People Actually Use

Wiki.js is one of the strongest self-hosted wiki options for teams that want modern documentation without adopting a bloated enterprise platform. It combines a polished interface with practical administration features, authentication options, and a structure that works for internal knowledge bases, team handbooks, and technical documentation.

The reason many people choose Wiki.js is not simply that it is open source. It is that it feels usable. Plenty of self-hosted documentation tools are technically capable but difficult to maintain or unpleasant for non-technical contributors. Wiki.js usually lands in a better place: modern enough for a small team, but straightforward enough for a solo operator.

A typical Wiki.js setup uses Node.js for the application and PostgreSQL for the database, deployed through Docker. That stack is common and well understood, which makes operations easier. If you already run containerized services, adding Wiki.js is not especially hard. The bigger challenge is designing the wiki so that people can actually find and trust information later. Let's handle the installation first, then the structure.

Installing Wiki.js with Docker Compose

The stable release in 2026 is still the 2.x line, and the officially recommended database is PostgreSQL. The whole stack fits in one Compose file. Create a directory and drop this in as docker-compose.yml:

services:
  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_USER: wikijs
      POSTGRES_PASSWORD: change-this-password
    volumes:
      - db-data:/var/lib/postgresql/data
    restart: unless-stopped

  wiki:
    image: ghcr.io/requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: change-this-password
      DB_NAME: wiki
    ports:
      - "127.0.0.1:3000:3000"
    restart: unless-stopped

volumes:
  db-data:

Change the password in both places, then start it:

docker compose up -d
docker compose logs -f wiki

Wiki.js retries the database connection on startup, so it tolerates PostgreSQL taking a few seconds to initialize. When the logs show the HTTP server listening on port 3000, open http://your-server-ip:3000 in a browser. The first-run wizard asks for three things:

• an administrator email and password
• the site URL
• whether to send anonymous telemetry

That is the entire install. Log in with the admin account, and you land in a working wiki with an empty content tree.

One gotcha worth knowing up front: the site URL you enter in the wizard is not cosmetic. Wiki.js uses it to build links and authentication callbacks. If you enter http://192.168.1.50:3000 during testing and later move the wiki behind a domain with HTTPS, log in as admin and update the site URL under Administration, then restart the container. Skipping that step is the classic cause of broken login redirects and asset links after going into production.

For production, do not expose port 3000 directly. Put a reverse proxy in front to terminate TLS and forward traffic to the container. If you have not picked a proxy yet, our Traefik vs. Nginx comparison covers the trade-offs for exactly this kind of single-app deployment. And since the database is the part you cannot afford to lose, schedule pg_dump from the db container as part of a real 3-2-1 backup strategy rather than relying on volume snapshots alone. Content in Wiki.js lives in PostgreSQL; the Git storage module is a sync target, not the source of truth, so backing up a Git mirror is a nice extra but not a substitute for database backups.

Plan the wiki before people start writing

With the software running, a practical setup plan comes down to four things:

• where the wiki will be hosted and how it will be backed up
• how users will authenticate
• who can edit which sections
• how the content tree will be organized before pages start multiplying

That last point matters more than the installation itself. Many teams succeed at deploying a wiki and fail at maintaining one. The problem is rarely software. It is weak structure. If every page lives at the top level, naming is inconsistent, and ownership is unclear, the wiki becomes a graveyard of half-updated notes.

Wiki.js helps by supporting permissions, navigation, themes, and integrations, but it cannot decide your documentation model for you. Before launch, define a clear top-level structure. A common pattern is:

• operations and infrastructure
• product or project documentation
• team processes
• onboarding and training
• policies and reference material

That gives contributors a starting map and reduces the chance that useful information disappears into random pages.

Authentication deserves careful thought too. For personal use, local accounts may be fine. For teams, single sign-on or directory integration is usually better, and Wiki.js ships with a long list of auth providers you can enable from the admin panel. The less password sprawl you create, the easier the wiki is to adopt. Access should also match the sensitivity of the information. Public docs, internal docs, and admin-only docs should not all live under one loose permission model just because it is simpler at first.

Another strong feature of Wiki.js is that it can support multiple editing patterns. Some teams prefer writing directly in the browser. Others prefer Git-backed workflows or markdown-heavy habits. The tool is flexible enough to support both technical and less technical contributors, which is one of the reasons it scales well for mixed teams.

Keep the operation boring

From an operations standpoint, keep the deployment unremarkable. Put it behind HTTPS, back up the database, update it regularly, and test restore procedures occasionally. The same habits that make any containerized service dependable apply here; our Docker Compose best practices for production guide covers pinning images, restart policies, and update routines that fit a deployment like this one. Wikis are deceptively important systems. When a wiki is healthy, people barely notice it. When it goes down during onboarding, an incident, or a process handoff, everybody suddenly remembers how much invisible work it was doing.

Search quality and content ownership also deserve attention. Every important section should have someone responsible for keeping it current. A wiki without ownership decays fast. Schedule light reviews instead of waiting for a major cleanup project that never happens.

My recommendation is to use Wiki.js if you want a modern self-hosted wiki that balances usability and operational sanity. Install it with a clear authentication plan, a defined page structure, and real backup discipline. Then focus less on making the wiki feature-rich and more on making it dependable. The best wiki is not the one with the most plugins. It is the one your team trusts enough to open before asking in chat.

That trust comes from consistency. If onboarding pages are current, runbooks are easy to find, and navigation makes sense, adoption follows naturally. If the wiki is messy, even excellent software will not save it. Wiki.js gives you a strong platform. The real win comes from using that platform to create a knowledge system people can actually rely on.

One useful practice is to assign review dates to critical pages such as runbooks, onboarding guides, and access procedures. Documentation decays quietly. A simple quarterly review is often enough to catch stale screenshots, outdated commands, or missing owners. Wiki.js makes publishing easy, but the long-term value comes from keeping high-impact pages current instead of assuming that once written means permanently accurate.

The example binds the application port to 127.0.0.1 on the host. For initial setup on a remote host, use an SSH tunnel or a private management connection; a public-server URL will not reach that loopback binding directly. Configure the authenticated HTTPS reverse proxy before making the service public.