Bitwarden’s self-hosted container finally runs rootless and read-only

September 3, 2026. Bitwarden ships version 2026.8.1 of its self-host repository, headlined by a community highlight: support for running the unified container rootless and with a read-only root filesystem. September 15. Version 2026.8.2 adds cap_drop: ALL to the example Docker Compose file. September 17. Version 2026.9.0 lands with no further substantive change. Why it matters: a self-hosted password manager is a special target — and the container running it still defaulted to root with a writable filesystem.

Why a password vault demands a locked-down container

The reasoning is easy to state and slow to accept: a self-hosted Bitwarden instance concentrates the most sensitive asset a homelab or small business owns — credentials, secrets, TOTP keys — in a single process. Compromise that process and the attacker does not steal a file; they steal the entire vault.

Until 2026.8.1, the unified Bitwarden image ran as root inside the container. On a container escape — through a vulnerable kernel, a mis-mounted volume, or a stray setuid binary — an attacker breaking out of the container landed as root on the host, with direct access to the data volumes. Running rootless does not eliminate escape risk, but it mostly neutralises it: an unprivileged process that escapes remains an unprivileged process, unable to write to /etc, load a kernel module, or read another container’s volume.

The second half, read-only, answers a different problem. A writable root filesystem lets an attacker who has achieved code execution persist — drop a binary, patch a startup script, tamper with a dependency. A read-only rootfs cuts that off at the root: whatever the container cannot write, the attacker cannot modify. The combination — rootless plus read-only — is the de facto standard for sensitive workloads, and a password manager is the most obvious case of all.

What 2026.8.1 actually changes under the hood

The request was not new. Two tickets had been sitting in the trackers: issue #247 in self-host (“Run Bitwarden-selfhosted as non-root container on the read-only filesystem”) and issue #2903 in server (“Container should not run as root”). Pull request #358, opened back in March 2025 by community contributor kaysond and merged for 2026.8.1, closes both.

The strategy fits in one sentence: move everything into /etc/bitwarden, a single directory meant to be bind-mounted from the host, where permissions can be managed cleanly. Files the entrypoint creates elsewhere are replaced with symlinks baked into the image; the PID and temp files for supervisord and nginx move to /tmp, following convention. The result: the container can run with a non-privileged user: and a read-only rootfs, provided a single volume — /etc/bitwarden — is writable.

The contributor made a deliberate, documented choice: the PUID and PGID environment variables are kept for backward compatibility, but he explicitly recommends removing them. Starting as root to “set everything up” and then dropping privileges needlessly widens the attack surface, when a single chmod/chown on one host directory suffices. He also flags a concrete incompatibility: combining PUID/PGID with a read-only rootfs makes the container fail, because it tries to add a group inside /run — a location that is now unwritable.

The logical next step: cap_drop: ALL in 2026.8.2

Version 2026.8.2, released on September 15, 2026, pushes the reasoning one step further. Its one notable maintenance change — again authored by kaysond — adds cap_drop: ALL to the rootless section of the example Compose file. A rootless container still holds certain Linux capabilities by default; dropping all of them forces the image to run without CAP_SYS_ADMIN, without CAP_NET_RAW, and without the other granular privileges an attacker might use for escalation.

It signals a deliberate direction: Bitwarden is progressively aligning its official image with the practices defenders had been asking for. The most secure example configuration now bundles all four levers — a non-root user:, read_only: true, cap_drop: [ALL], and security_opt: no-new-privileges:true — in a single reproducible block.

services:
  bitwarden:
    image: bitwarden/self-host:beta
    user: "1000:1000"
    read_only: true
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    tmpfs:
      - /tmp
      - /run
    volumes:
      - ./bwdata:/etc/bitwarden

The tmpfs mounts on /tmp and /run are essential: these are the only two places the container must be able to write at runtime, while the rest of the filesystem stays locked. The ./bwdata:/etc/bitwarden volume is the single persistent write point, and therefore the only directory you need to protect on the host.

Verdict

Rootless and read-only are not a visible feature — they are a structural hardening, the kind of change you never notice when it works and pay for dearly when it is missing. If you self-host Bitwarden, schedule the upgrade to 2026.8.1 (or straight to the 2026.9.0 released September 17) without delay, checking that your Compose no longer leans on PUID/PGID and that /etc/bitwarden is mounted and restricted. If you are still weighing the official image against a reimplementation like Vaultwarden, this hardening rebalances the ledger on the official side: Vaultwarden’s lightness remains a point in its favour, but the official image has now closed its biggest gap in default posture. If you maintain other sensitive containers, treat this case as a template: any service that holds secrets deserves read_only: true, a non-root user:, and cap_drop: [ALL] — and the only real question is not whether you will do it, but when.

References

• Bitwarden — Releases, bitwarden/self-host, v2026.8.1 (September 3, 2026)
• Bitwarden — Pull request #358 “Add support for running rootless and with readonly filesystem”
• Bitwarden — Issue #247 “Run Bitwarden-selfhosted as non-root container on the read-only filesystem”
• Bitwarden — Issue #2903 “Container should not run as root” (bitwarden/server)
• Bitwarden — Releases, v2026.8.2 “add cap_drop ALL to example docker compose rootless section” (September 15, 2026)
• selfh.st — Self-Host Weekly (September 11, 2026)