linuxserver/bookstack is the BookStack wiki packaged for s6 and Alpine

Packaging, not the application

The linuxserver/bookstack repository is a Docker container for the BookStack documentation wiki, and the distinction in that sentence matters.

BookStack itself is a free and open source wiki designed for creating beautiful documentation, with a simple but powerful WYSIWYG editor, powered by SQL, and including a Markdown editor for those who prefer it. It lives on Codeberg, at codeberg.org/bookstack/bookstack, and the container documentation links to its own site and its own documentation.

The LinuxServer.io team describes what the container release adds, and the list is the value proposition. Regular and timely application updates, easy user mappings through PGID and PUID, a custom base image with an s6 overlay, weekly base OS updates with common layers across the entire LinuxServer.io ecosystem to minimise space usage, down time and bandwidth, and regular security updates.

The last of those is the one that matters most in practice. A wiki holding internal documentation is a container that has to be patched on a schedule, and the shared base image means the OS layer is rebuilt weekly across every container in the ecosystem, so the same CVE fix arrives in BookStack at the same time as in the others.

The repository is a small set of files. There is a Dockerfile, a Dockerfile.aarch64 for the ARM build, a Jenkinsfile, jenkins-vars.yml and readme-vars.yml for the build pipeline, a root/ directory holding the container's own files, and a package_versions.txt recording what went into the image. The README begins with a line saying it should not be edited manually, because it is generated from a template.

The base image and the s6 overlay

The container is built on the LinuxServer base image, and the first lines of the Dockerfile say which one and with which build arguments.

FROM ghcr.io/linuxserver/baseimage-alpine-nginx:3.24

ARG BUILD_DATE
ARG VERSION
ARG BOOKSTACK_RELEASE

So it is Alpine with nginx, and the build is parameterised by the build date, the container version and the BookStack release to fetch. The label records the container version and the build date, and the maintainer is set to thespad, which is the long standing LinuxServer maintainer name.

The supervision layer is s6, and the Dockerfile sets S6_STAGE2_HOOK to /init-hook, which is the hook the s6 overlay runs at the start of its second stage. That is how the container's own setup runs before the application services start.

The PHP side is configured in a way that has a visible consequence for the user, and it is easy to miss. The Dockerfile edits the php-fpm configuration to set clear_env to no.

    sed -E -i 's/^;?clear_env ?=.*$/clear_env = no/g' /etc/php85/php-fpm.d/www.conf

By default, php-fpm clears the environment for the workers it forks, which would mean the environment variables you pass to the container never reach the application. Setting clear_env to no is what makes APP_URL, the database settings and the other variables in your compose file visible to BookStack. The Dockerfile also writes a PATH environment entry into the main php-fpm config so the workers can find the tools the application shells out to.

The runtime packages installed alongside are the ones BookStack needs: the mariadb client, memcached with a PHP extension, and the PHP extensions for the DOM, exif, gd, ldap, mysqlnd, pdo_mysql, memcached and tokenizer, plus fontconfig and freetype fonts so the editor renders text correctly.

The release is fetched from Codeberg at build time

The build resolves the BookStack release itself rather than pinning a URL by hand, and the logic is worth reading because it explains how the container tracks upstream.

If the BOOKSTACK_RELEASE build argument is not set, the Dockerfile queries the Codeberg API for the latest release and reads the tag_name out of the JSON with jq. It then downloads the source archive for that tag, extracts it into /app/www with the top level directory stripped, and runs composer install inside it.

So the image contains a real Composer install of the upstream source, not a prebuilt artefact. That is what lets the container ship a specific set of PHP extensions, and it is also why the build takes a while.

The last part of the build is the symlinks, and this is the mechanism behind the persistence model. The Dockerfile creates symlinks for the application directories that have to survive an image upgrade, pointing them at locations inside /config, and the documentation explains the same thing from the user's side. The container ensures certain BookStack application files and folders, such as user file upload folders, are retained within the /config folder so that they are persistent.

That is the pattern to understand. The application code is baked into the image and is replaced on every upgrade, while the mutable parts, the uploads, the themes, the images, the backups and the framework cache, are symlinked into the volume. An upgrade replaces the image, and the volume keeps the things that must not be lost.

MariaDB, port 6875 and a default password in the README

Two operational facts are stated in the Application Setup section, and one of them is a security item you should not skip.

The first is the database. This application is dependent on a MariaDB database, be it one you already have or a new one, and for the second case the project provides a separate image, linuxserver/docker-mariadb. So a BookStack install is a two container deployment, a web container and a database container, or a web container pointing at a database you already run.

The second is how you reach it. The container listens on port 6875, and you access it at http://<host ip>:6875.

And the third is the credential, which the README spells out without hesitation. The default username is [email protected] with the password of password.

That is normal for a first-run flow in an application, and it is not normal to leave it in place. Anyone who finds the port and types the documented pair gets administrator access to your documentation wiki. The first thing to do after the first start is to change it, and the second thing is to decide whether the wiki is reachable from outside your network at all, because a documentation wiki behind a reverse proxy is often published more widely than the documentation it holds.

The documentation also points to the BookStack documentation site for the application's own configuration, which is the right place to look for anything about the wiki itself rather than the container.

APP_URL is the reverse proxy trap

There is one configuration note in the setup section that has bitten enough people to be worth repeating, and it concerns reverse proxies.

If you intend to use the application behind a subfolder reverse proxy, such as the SWAG container or Traefik, you will need to make sure that the APP_URL environment variable is set to your external domain, or it will not work.

The reason is that BookStack generates absolute URLs. It uses the application URL to build the links it writes into pages, into emails and into the API responses, and if the application believes it lives at one address while the proxy serves it at another, the links it produces point at the wrong place. The symptom is usually a redirect loop or links that escape the subfolder, and the cause is invisible because the container configuration looks right.

That is a common shape of problem with proxied containers, and the difference here is that the application is opinionated about its own address. The setting is a string in the environment, not a file, and it is worth setting it once at deploy time rather than discovering it later.

The other piece of the setup is the persistence model described earlier, with the application files kept inside the /config folder. The two together are the whole configuration surface of this container, and it is a short list, which is a virtue for something that runs unattended on a home server.

Multi-arch tags and a release cadence measured in weeks

The container is published for two architectures, and the naming scheme tells you how to pin a build.

The Supported Architectures section explains that the project uses the docker manifest for multi-platform awareness, and that simply pulling the latest tag should retrieve the correct image for your architecture, while specific arch images are available through their own tags. The table lists x86-64 as amd64 with a version tag, and arm64 as arm64v8 with a version tag.

So a tag of the form linuxserver/bookstack:latest is a manifest list, and a tag of the form amd64-v26.09.1-ls288 or arm64v8-v26.09.1-ls288 is a specific image for one architecture. For a deployment that must not change under you, the arch specific tag with a version is the one to use, and the base image is the same 3.24 tag in both cases, so the layers are shared.

The release naming is the other thing to understand, and it is dense. The recent releases are v26.09.1-ls288 from 2026-10-13, v26.09.1-ls287 from 2026-09-30 and v26.09-ls286 from 2026-09-28. The first part is the BookStack version, 26.09.1, and the second is the LinuxServer build counter, ls288.

That means the container has its own version line that moves independently of the application, which is what you want from a packager and what makes the tags long. The releases come every week or two, and the last push was on 2026-10-13, the same day as the newest tag, so the build pipeline is what the repository is for.

Editorial conclusion

Adopt the linuxserver container for BookStack if you want a wiki that updates on a predictable cadence, keeps its data in a volume that survives image upgrades, and runs on a NAS or a home server without you assembling a PHP environment. Do not adopt it if you need to modify the application code, because the image is rebuilt from the upstream release at build time rather than from a fork. Verify first that you have a MariaDB instance to point it at, that APP_URL is set to your external domain if you sit behind a subfolder reverse proxy, and that you change the default admin credentials, because the README ships them as [email protected] and password.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. linuxserver/docker-bookstack on GitHub
4. README
5. Releases