Apps / Docker Images
Vaultwarden in Docker.
Your vault, your server.
Vaultwarden is a lightweight, Bitwarden-compatible password manager server written in Rust. It speaks the Bitwarden API, so the official Bitwarden desktop, mobile, browser, and CLI clients connect to it directly, while it runs with a fraction of the resources of the full Bitwarden server stack.
docker pull ghcr.io/remarkablecloud/vaultwarden Current build
1-r1
Updated Sep 10, 2026
Base
Vaultwarden official, digest-pinned
What's inside
Bitwarden-compatible API, SQLite on one /data volume, signup lockdown notes
Upstream license
Vaultwarden: AGPL-3.0-only
Free to pull and run anywhere. Digest-pinned, updated deliberately; each build is recorded in the changelog.
The image
What our image adds.
Vaultwarden is a lightweight, Bitwarden-compatible password manager server written in Rust. It speaks the Bitwarden API, so the official Bitwarden desktop, mobile, browser, and CLI clients connect to it directly, while it runs with a fraction of the resources of the full Bitwarden server s
Digest-pinned base
for reproducible, auditable builds.
OCI provenance labels
(title, description, vendor, source) for supply-chain traceability.
Built-in healthcheck
against Vaultwarden's `/alive` endpoint, so an orchestrator only routes traffic to a ready instance. The `1-r1` tag tracks the upstream 1.x line and is pinned by digest to the 1.37.2 release. Vaultwarden's own features are unchanged.
Rather skip the compose file? Deploy Vaultwarden with one click on your own VPS: TLS, domain and database already wired.
Deploy Vaultwarden in one clickThe guide
Run it in production.
docker-compose walkthrough
The image ships a standalone docker-compose.yml:
name: vaultwarden
services:
vaultwarden:
image: ${VW_IMAGE:-ghcr.io/remarkablecloud/vaultwarden:1-r1}
restart: unless-stopped
ports: ["${HTTP_PORT:-8086}:80"]
environment:
DOMAIN: ${DOMAIN:-http://localhost:8086}
SIGNUPS_ALLOWED: ${SIGNUPS_ALLOWED:-true}
volumes:
- vw-data:/data
volumes:
vw-data:
Line by line:
- image pins the RemarkableCloud Vaultwarden tag, overridable with
VW_IMAGE. - restart: unless-stopped brings the container back after a crash or reboot.
- ports maps host port 8086 to container port 80. This is for standalone runs only. Behind Traefik, no port is published; the proxy routes to port 80 on the internal network.
- DOMAIN is the public URL of the server and must be exact (see the reference below).
- SIGNUPS_ALLOWED controls open registration.
- volumes mounts the
vw-datavolume at/data, which holds the SQLite database, attachments, RSA keys, andconfig.json.
Set your real URL and start it, for example DOMAIN=https://vault.example.com docker compose up -d. Open the URL, create your account, then close registration.
Environment variable reference
| Variable | App Platform value | Standalone default | Notes |
|---|---|---|---|
DOMAIN | https://your-hostname | http://localhost:8086 | The exact public URL of the server. WebAuthn and two-factor authentication, attachment and Send links, and email links all depend on it being correct and using https in production. |
SIGNUPS_ALLOWED | true | true | Whether new users can self-register. Set to false after you create your account. |
HTTP_PORT | not applicable | 8086 | Host port mapped to container port 80 in standalone compose only (not published behind Traefik). |
VW_IMAGE | not applicable | ghcr.io/remarkablecloud/vaultwarden:1-r1 | Image reference override for standalone compose. |
Hardening notes
- Close registration. The catalog ships with
SIGNUPS_ALLOWED=trueso you can create the first account. Set it tofalseimmediately afterward so no one else can register. For controlled onboarding later, use Vaultwarden’s invitation flow instead of reopening sign-ups. - Set DOMAIN correctly. WebAuthn and two-factor authentication are bound to the exact origin. Use the real public https URL, with no trailing slash and no port.
- TLS at the proxy. In production the container serves plain HTTP on port 80 and Traefik terminates TLS. Keep the container off any public port and let the proxy reach it internally. Vaultwarden should always be reached over HTTPS.
- Admin panel is off by default. Vaultwarden’s
/adminpanel stays disabled until you set anADMIN_TOKENenvironment variable (an upstream option). This image does not set one. If you enable it, use a long random token, ideally an Argon2 hash as documented upstream. - Runs as root. The upstream server runs as root. Keep it isolated behind the proxy and do not publish its port.
Backup and upgrade
Backup. All state lives in the vw-data volume at /data: the SQLite database (db.sqlite3), uploaded attachments, the RSA key files, and config.json. Back up the whole volume on a schedule. The RSA key files matter: keep them, or existing sessions and some tokens are invalidated after a restore. For a consistent database copy, either stop the container briefly before copying the volume, or run the SQLite backup API against the mounted database from the host or any container that has the sqlite3 CLI (for example sqlite3 db.sqlite3 ".backup 'backup.sqlite3'"), so you never capture a database mid-write.
Upgrade. Pull the newer RemarkableCloud tag and recreate the container. The vw-data volume persists, so vaults, attachments, and keys carry over. Vaultwarden runs any needed schema migrations on start, and because it uses SQLite there is no separate database server to upgrade. Read the CHANGELOG for the target tag first, and back up the volume before upgrading.
Updates
Recent builds.
1-r1
Sep 10, 2026Initial RemarkableCloud build of Vaultwarden. - **Upstream:** Vaultwarden 1.37.2 (Bitwarden-compatible server written in Rust; SQLite, no external database).
Or skip the ops
Host Vaultwarden on your own private VPS.
One click installs this exact image on a VPS that is yours alone, domain and TLS wizard included. The same server runs as many apps as fit, with no per-app charge.
FAQ
Questions we get.
Which clients work with Vaultwarden?
The official Bitwarden clients (desktop, mobile, browser extensions, and CLI) connect to Vaultwarden, since it implements the Bitwarden API. Point the client's server URL at your `DOMAIN`.
Do I need an external database?
No. Vaultwarden uses SQLite stored in the `/data` volume. There is no separate database container.
How do I stop other people from registering?
Set `SIGNUPS_ALLOWED=false` after creating your account. Add users later with Vaultwarden's invitation feature.
Why must DOMAIN be exact?
WebAuthn and two-factor authentication are tied to the exact origin, and attachment, Send, and email links are built from `DOMAIN`. A wrong value breaks those features.
Where is my data stored?
In the `vw-data` volume at `/data`: the SQLite database, attachments, RSA keys, and configuration.
Your server runs. You sleep.
Fully managed hosting from people who have been doing this since 2001.