Vaultwarden Infrastructure

02 / Problem

Problem

A self-hosted password service adds operational responsibility. A copied database is not enough if attachments, keys and configuration do not match its state, and an application login should not expose server administration.

03 / Objectives

Objectives

Keep public HTTPS access usable, restrict registration and administration, use a second authentication factor, and create database-consistent recovery material.

04 / ARCHITECTURE

Follow the components.

HTTPS clients
Application tunnel
Vaultwarden
SQLite & attachments
Recovery snapshot

05 / Implementation

Implementation

Vaultwarden runs in Docker behind its application tunnel. Registration and the application administration panel are disabled. TOTP enrollment with Aegis was recorded in the homelab setup. The recovery script briefly quiesces the service, uses SQLite’s backup facility and captures attachments and configuration alongside the database.

06 / SECURITY

Security boundaries

Human credentials and recovery codes never enter the portfolio.
Public application access does not publish private administration.
Backup material is protected and is not served by the website.

07 / Testing

Testing

The running container reports healthy, and both the public HTTPS endpoint and local application origin returned successfully. The latest configuration backup exited successfully; its script checks SQLite integrity before marking the snapshot complete. Fresh client TOTP enrollment was not repeated in this session.

08 / Challenges

Challenges

Recovery must include more than the main database file. A consistent capture needs to account for attachments and keys, and protected backup permissions matter because the recovery material is sensitive.

09 / Lessons

Lessons

Authentication controls and operational recovery solve different problems. Both need attention. The current local snapshots still require an independent physical copy for disk-failure protection.