About this project

This repository packages a self-hosted XWiki deployment as a single Docker Compose stack. XWiki, an enterprise wiki platform, runs behind Traefik acting as reverse proxy, with Let's Encrypt certificates issued automatically for the configured hostnames. PostgreSQL 15 stores the wiki data. Setup follows a short sequence: clone the repository, create the two expected Docker networks (traefik-network and xwiki-network), copy .env.example to .env and fill in the required values (XWIKI_DB_PASSWORD, XWIKI_HOSTNAME, TRAEFIK_HOSTNAME, TRAEFIK_ACME_EMAIL, TRAEFIK_BASIC_AUTH), then bring the stack up with docker compose. The README notes that first start takes several minutes while XWiki initializes its schema and core pages, and lists common first-deploy problems such as certificate issuance failing because DNS has not propagated or port 80 is not reachable, network errors from skipping the network-creation step, and missing-variable failures. An update.sh script moves the checkout to the latest release tag and re-runs docker compose up. It refuses to cross a major version unattended, refuses to run over local changes, and reports any variable that became required since the installed version. A --dry-run flag previews the action. Three Docker Hub official images (traefik, xwiki, postgres) are pinned to tag@sha256 digests as interpolation defaults, so a plain git pull delivers the tested combination. Per-image override levels are documented: a version variable swaps only the tag without a digest, while a tag variable replaces the whole reference. Nested defaults require Docker Compose v2.5 or newer. A daily CI job re-resolves pins against the registries and compares pinned XWiki and Traefik versions with upstream releases; GitHub Actions are pinned by commit SHA and kept fresh by Dependabot. Backups are handled by a dedicated container that runs a pg_dump piped through gzip plus a tar.gz archive of the wiki data, then prunes old backups and sleeps. Defaults are a 30-minute warm-up, a 24-hour interval and 7-day retention. Two interactive restore scripts cover the database and the application data. The repository advises host-mounting the backup volumes and backing up before upgrades because XWiki migrates its schema on version jumps. Hardening is applied uniformly: every service sets no-new-privileges, infrastructure containers drop all capabilities and add back only what their entrypoints need (NET_BIND_SERVICE for Traefik, CHOWN/SETUID/SETGID for database images), while application containers keep the default capability set deliberately. Each service carries memory and CPU limits plus reservations as compose defaults, overridable through .env variables. A Deployment Verification workflow runs on every push, pull request and daily at 06:00 UTC, covering shellcheck, actionlint, Trivy scans of the three pinned images, the freshness check, and a deploy-and-test job that boots the stack with ephemeral credentials and requires the wiki UI to answer through Traefik. An end-to-end backup/restore script inserts a marker row, restores the earliest backup and asserts the marker is gone; it briefly stops the database container to prove failure detection and is meant for staging rather than production. Security notes state that credentials are read from a gitignored .env at deploy time, that PostgreSQL listens only on the internal network, and that releases before v1.0.0 shipped a tracked .env with a generated-looking database password that should be rotated if reused.