TomSecSECURITY / SYSTEMS
TOMSEC / PUBLIC TERMINAL

READ-ONLY SESSION · CHOOSE A SYSTEM TO INSPECT

~/search
← ~/PROJECTS

TOMSEC / TECHNICAL CASE FILE PUBLIC INFORMATION ONLY

Security / InfrastructureOperating

Vaultwarden Infrastructure

The work here is operating the password service: separating application access from administration, controlling registration and preparing recovery material without copying an inconsistent live database.

VaultwardenDockerSQLiteHTTPSTOTPAegis

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.

FRAME / 02 · CONCEPTUAL TOPOLOGY

Component inspection

EDITORIAL VIEW
NO PRIVATE TELEMETRY
Component inspection Select a node to inspect its role.NODE 01HTTPS CLIENTSNODE 02APPLICATION TUNNELNODE 03VAULTWARDENNODE 04SQLITE & ATTACHMENTSNODE 05RECOVERY SNAPSHOT

Select a component to inspect its role. Lines show the application dependencies and supporting services.

INSPECT / HTTPS CLIENTS

Password clients use the published HTTPS application. Owner administration and host access remain separate.

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.