Podman is a daemonless alternative to Docker, which is mostly compatible with Docker containers.
Creating a Quadlet (Podman 4.4+)
As of version 4.4, Podman uses quadlets and will show a warning if you use the previous generate systemd method.
Additional benefit is that this method will keep the container updated.
Configuration via environment file
Configuration may be easier in an environment file and less error-prone.
NOTE: this file contains secrets, make sure only root has access!
sudo install -o0 -g0 -m600 /dev/null /etc/vaultwarden.env
sudo vi /etc/vaultwarden.env
# Contents of /etc/vaultwarden.env
ROCKET_PORT=8080
# DISABLE_ADMIN_TOKEN=true
# ADMIN_TOKEN=$argon2id$...
# LOG_LEVEL=debug
Creating the podman quadlet
Configuration looks like systemd's but we configure a Container, not a Unit. See the documentation for all [Container] directives.
# Content of /usr/share/containers/systemd/vaultwarden.container
[Unit]
Description=Vaultwarden container
After=network-online.target
[Container]
Image=ghcr.io/dani-garcia/vaultwarden:latest
Exec=/start.sh
EnvironmentFile=/etc/vaultwarden.env
Volume=/vw-data/:/data/
PublishPort=8080:8080
[Install]
WantedBy=default.target
After editing the quadlet, run systemctl daemon-reload to create or updates the systemd unit. You control this container using regular systemctl commands.
Creating a systemd service file (older Podman versions)
Podman is easier to run in systemd than Docker due to its daemonless architechture. It comes with a handy generate systemd command which can generate systemd files. Here is a good article that goes into more detail as well as this article detailing some more recent updates.
$ podman run -d --name vaultwarden -v /vw-data/:/data/:Z -e ROCKET_PORT=8080 -p 8080:8080 vaultwarden/server:latest
54502f309f3092d32b4c496ef3d099b270b2af7b5464e7cb4887bc16a4d38597
$ podman generate systemd --name vaultwarden
# container-vaultwarden.service
# autogenerated by Podman 1.6.2
# Tue Nov 19 15:49:15 CET 2019
[Unit]
Description=Podman container-vaultwarden.service
Documentation=man:podman-generate-systemd(1)
[Service]
Restart=on-failure
ExecStart=/usr/bin/podman start vaultwarden
ExecStop=/usr/bin/podman stop -t 10 vaultwarden
KillMode=none
Type=forking
PIDFile=/run/user/1000/overlay-containers/54502f309f3092d32b4c496ef3d099b270b2af7b5464e7cb4887bc16a4d38597/userdata/conmon.pid
[Install]
WantedBy=multi-user.target default.target
You can provide a --files flag to tell podman to put the systemd service into a file or use podman generate systemd --name vaultwarden > /etc/systemd/system/container-vaultwarden.service. With this we can enable and start the container as any normal service file.
$ systemctl enable /etc/systemd/system/container-vaultwarden.service
$ systemctl start container-vaultwarden.service
New container every restart
If we want to create a new container every time the service starts we can use the podman generate systemd --new command to generate a service file that recreates containers
$ podman generate systemd --new --name vaultwarden
If you're using an older Podman, you can edit the service file to contain the following instead:
[Unit]
Description=Podman container-vaultwarden.service
[Service]
Restart=on-failure
ExecStartPre=/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStart=/usr/bin/podman run --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid --env-file=/home/spytec/Vaultwarden/vaultwarden.conf -d -p 8080:8080 -v /home/spytec/Vaultwarden/vw-data:/data/:Z vaultwarden/server:latest
ExecStop=/usr/bin/podman stop -t "15" --cidfile /%t/%n-cid
ExecStop=/usr/bin/podman rm -f --cidfile /%t/%n-cid
KillMode=none
Type=forking
PIDFile=/%t/%n-pid
[Install]
WantedBy=multi-user.target default.target
Where vaultwarden.conf environment file can contain all the container environment values you need
ROCKET_PORT=8080
If you want the container to have a specific name, you might need to add ExecStartPre=/usr/bin/podman rm -i -f vaultwarden if the process isn't cleaned up correctly. Note that this method currently doesn't work with the User= options users (see https://github.com/containers/podman/issues/5572).
Troubleshooting
Debugging systemd service file
If the host goes down or the container crashes, the systemd service file should automatically stop the existing container and spin it up again. We can find the error through journalctl -u container-vaultwarden -t 100.
Most of the time the errors we see can be fixed by simply upping the timeout in Podman command in the service file.
FAQs
Container Image Usage
- Which container image to use
- Starting a container
- Updating the vaultwarden image
- Using Docker Compose
- Using Podman
Deployment
- Building your own docker image
- Building binary
- Pre-built binaries
- Third-party packages
- Deployment examples
- Proxy examples
- Logrotate example
HTTPS
Configuration
- Overview
- Disable registration of new users
- Disable invitations
- Enabling admin page
- Disable the admin token
- Enabling WebSocket notifications
- Enabling Mobile Client push notification
- Enabling U2F and FIDO2 WebAuthn authentication
- Enabling YubiKey OTP authentication
- Changing persistent data location
- Changing the API request size limit
- Changing the number of workers
- SMTP configuration
- Translating the email templates
- Password hint display
- Disabling or overriding the Vault interface hosting
- Logging
- Creating a systemd service
- Syncing users from LDAP
- Using an alternate base dir (subdir/subpath)
- Other configuration
Database
- Using the MariaDB (MySQL) Backend
- Using the PostgreSQL Backend
- Running without WAL enabled
- Migrating from MariaDB (MySQL) to SQLite