How to Self-Host DokuWiki in 2026: File Storage, ACLs and Backups

Treat DokuWiki as a small system, not a Docker image. The user-facing goal for DokuWiki is clear: file-backed wiki that needs no database; the deployment is acceptable only when you can replace setup credentials, edit a page, upload media, apply an ACL, view a revision and restore an older version.

That distinction catches the failure mode operators meet after local testing: file ownership prevents page saves even though the UI loads. It also makes the backup and upgrade plan specific enough to test.

Ports, processes and private services

Start with the DokuWiki network namespace: its web listener is port 80, not a host port copied from a laptop tutorial. The local runtime requirement is a persistent config volume containing pages, media and ACLs. Document the expected capacity, ownership and failure mode rather than leaving it as an image default.

After the requirement is satisfied, run the complete scenario — replace setup credentials, edit a page, upload media, apply an ACL, view a revision and restore an older version. Record logs and measurements for filesystem metadata, media volume, search indexing and PHP workers. That evidence becomes the first known-good architecture and makes later moves between Dockup compute and an attached server testable.

Failure drills for DokuWiki

A green container is necessary but not sufficient. The service-level indicator is successful completion of “replace setup credentials, edit a page, upload media, apply an ACL, view a revision and restore an older version”, while the likely pressure signals are filesystem metadata, media volume, search indexing and PHP workers.

Change control matters because plugins and templates can lag DokuWiki releases even though plain page files remain readable. Preserve the old image, test migrations on copied state and document whether rollback is supported after the schema moves. If file ownership prevents page saves even though the UI loads, diagnose the first boundary that differs from the working environment.

Record a known-good DokuWiki deployment

A release candidate for DokuWiki earns traffic by completing a fixed scenario: replace setup credentials, edit a page, upload media, apply an ACL, view a revision and restore an older version. Capture the image digest, effective non-secret configuration, public origin and timestamps for that scenario. The test data should be disposable but realistic enough to exercise the same path as users.

Run it after replacing the runtime, then rebuild the service from pages, media, metadata, users, ACLs and plugins. Recovery passes when pages, revisions, media, users, ACLs and plugins return and the protected page remains protected. Compare resource measurements for filesystem metadata, media volume, search indexing and PHP workers with the prior release and investigate meaningful drift before promotion.

Finally, exercise this controlled failure: submit harmless input near the resource or format limit associated with this boundary: file ownership prevents page saves even though the UI loads. Verify that DokuWiki explains the failure, does not damage existing state and resumes after the valid condition returns. Save a redacted log excerpt and the recovery time. Together these checks cover behavior, durability and operability rather than just process uptime.

Run the first production-shaped instance

Use a command that exposes every important choice. This baseline binds DokuWiki to host loopback, adds the known data mounts and supplies the first required setting. Confirm the local requirement before exposure: a persistent config volume containing pages, media and ACLs.

docker run -d \
  --name dokuwiki \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v dokuwiki-data:/config \
  lscr.io/linuxserver/dokuwiki:latest

Replace floating tags with a tested version or digest. After startup, inspect docker logs --tail 200 dokuwiki and confirm the process listens on 80. Then execute the DokuWiki acceptance action; a root-page response cannot prove the full scenario succeeds: replace setup credentials, edit a page, upload media, apply an ACL, view a revision and restore an older version.

Volumes are only the first recovery layer

For DokuWiki, redeploy safety starts with pages, media, metadata, users, ACLs and plugins. Mount /config before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Test the path by replacing the container while harmless sample data exists; this exposes mounts pointed one directory too high or low.

Next test disaster recovery on a blank host. Use an application-consistent database export where necessary and verify that pages, revisions, media, users, ACLs and plugins return and the protected page remains protected. The restore-tested database backup guide provides a stronger target than merely checking that an archive file was created.

Give DokuWiki one canonical address

TLS issuance is only half of the DokuWiki route. Serve the wiki over HTTPS and set its canonical base URL. Send traffic internally to 80 and forward the external scheme so generated URLs and secure cookies remain consistent.

Use the complete DokuWiki scenario from a clean network, not merely the root page. A 502 or certificate failure can be isolated with automatic domain and TLS setup. If traffic reaches the process and file ownership prevents page saves even though the UI loads, diagnose that condition where it occurs instead of stacking redirects.

Close temporary setup access

Threat-model the action DokuWiki performs, not just its login form. Here the high-risk mistake is leaving the installer or registration settings open. Implement this boundary: remove installer access, review registration and preserve ACL files together with page content.

DokuWiki has no mandatory bootstrap secret in this baseline; protect its actual administrator account or upstream authentication instead. Do not solve a permission error by running the container as root or mounting the host broadly. Resource limits also belong to the security design when filesystem metadata, media volume, search indexing and PHP workers can be triggered by users.

Use Dockup for the platform layer

A Dockup template should encode the image, port 80, mounts, health timing, domain, TLS and secret delivery. Dockup should preserve the DokuWiki runtime settings while the operator confirms this local requirement: a persistent config volume containing pages, media and ACLs. The same deployment can target Dockup servers or customer-attached capacity.

After the route is live, apply the public setting and try to replace setup credentials, edit a page, upload media, apply an ACL, view a revision and restore an older version. Back up pages, media, metadata, users, ACLs and plugins and keep the restore exercise in the operating plan; those are DokuWiki responsibilities that remain visible after infrastructure provisioning.

Frequently asked questions

What does DokuWiki need for a production deployment?

Route the DokuWiki container on port 80 through one HTTPS origin. The local runtime requirement is a persistent config volume containing pages, media and ACLs. Do not call DokuWiki ready until you can replace setup credentials, edit a page, upload media, apply an ACL, view a revision and restore an older version.

Which DokuWiki data belongs in a backup?

Persist /config and include pages, media, metadata, users, ACLs and plugins in the same recovery manifest. A clean DokuWiki restore passes only when pages, revisions, media, users, ACLs and plugins return and the protected page remains protected.

Does DokuWiki require HTTPS behind a reverse proxy?

Use HTTPS for the public DokuWiki origin and keep port 80 on the internal route. Apply the DokuWiki setting correctly: serve the wiki over HTTPS and set its canonical base URL. For DokuWiki, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a DokuWiki upgrade be tested?

Restore current DokuWiki state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because plugins and templates can lag DokuWiki releases even though plain page files remain readable. Keep the previous DokuWiki image until its data-migration and rollback boundary are understood.