Vaultwarden¶

Overview¶

As the docs say Vaultwarden is "An alternative server implementation of the Bitwarden Client API, written in Rust and compatible with official Bitwarden clients [...], perfect for self-hosted deployment where running the official resource-heavy service might not be ideal."
It stores passwords and it is compatible with Bitwarden clients. Thats it.

Structure¶

Reverse Proxy¶

The reverse proxy (Caddy) handles TLS and domain management.
The Vaultwarden container listens on port 80 by default, but I changed it to port 1111 by default, which is customizable.
The domain it uses must be changed in vars.yml. See Caddy documentation.

Quadlet (or rather Podman)¶

It's Ansible who creates the container so here are the snippets from roles/vaultwarden/tasks/main.yml:

    - name: Run Vaultwarden container
      containers.podman.podman_container:
        name: vaultwarden
        image: "{{ vaultwarden_image }}"
        state: started
        restart_policy: unless-stopped

        user: "{{ uid }}:{{ guid }}"

        volumes:
          - "/{{ parent_dir }}/{{ vaultwarden_dir }}:/data:Z"

        env:
          ROCKET_PORT: "{{ vaultwarden_port }}"
          ROCKET_ADDRESS: "0.0.0.0"
          SIGNUPS_VERIFY: "{{ signups_verify }}"

        network:
          - "{{ podman_network }}"
      when: vaultwarden_bootstrap and not signups_allowed

    - name: Run Vaultwarden container
      containers.podman.podman_container:
        name: vaultwarden
        image: "{{ vaultwarden_image }}"
        state: started
        restart_policy: unless-stopped

        user: "{{ uid }}:{{ guid }}"

        volumes:
          - "/{{ parent_dir }}/{{ vaultwarden_dir }}:/data:Z"

        env:
          ROCKET_PORT: "{{ vaultwarden_port }}"
          ROCKET_ADDRESS: "0.0.0.0"
          SIGNUPS_ALLOWED: "{{ signups_allowed }}"
          SIGNUPS_VERIFY: "{{ signups_verify }}"

        network:
          - "{{ podman_network }}"

First boot behaviour¶

But wait.. there's two containers? Not quite.
You see Vaultwarden allows you to forbid new signups with an env variable.
And since it's exposed over Cloudflare Tunnel, theoretically anyone with the domain could make an account.
To prevent that, on the first run (or when you change vaultwarden_bootsrap variable in roles/vaultwarden/vars/main.yml) it allows signups, then after you made your account (and with pressing Enter signalled to Ansible you are done), it recreates the container but now forbids account creation:

Required variables¶

1. Set vaultwarden_domain variable in global vars.yml file.
2. vaultwarden_bootstrap set to true in roles/vaultwarden/vars/main.yml on your first run. (After, manually set it to false)
3. podman_network variable filled in global vars.yml file.
4. vaultwarden_port variable filled in global vars.yml file. (I tested 1111, that is confirmed to work).

Directory layout¶

If you leave the defaults, the directory layout will look like this:

/stack/
  vaultwarden-data/

Customizations¶

1. You can change where they store the data by editing roles/vaultwarden/defaults/main.yml and/or by changing the parent directory in vars.yml.
2. To change whether you can sign up after first install or you must verify your e-mail, change signups_allowed and signups_verify in roles/vaultwarden/defaults/main.yml (see in table).
3. To change its port, change vaultwarden_port in vars.yml.

roles/vaultwarden/defaults/main.yml

Dependencies¶

It really does not have many dependencies, as Ansible handles them anyways. The only thing you have to do is following the Required variables section.

Backups¶

Creating the backup¶

rsync -a --no-xattrs /<parent_dir>/<vaultwarden_dir>/ /tmp/vaultwarden-data-bak && 7z a -p"password" vaultwarden-backup.7z /tmp/vaultwarden-data-bak && rm -rf /tmp/vaultwarden-data-bak

Restoring the backup¶

7z x vaultwarden-backup.7z -ppassword -o/<parent_dir>/vaultwarden-restore

Replace your old directory's data¶

cp -R /<parent_dir>/vaultwarden-restore /<parent_dir>/<vaultwarden_dir> && rm -rf /<parent_dir>/vaultwarden-restore && chown -R nobody:nobody /<stack>/<vaultwarden_dir>

Bugs¶

None as far as I know