Stand: 2026-08-05 (erhoben per SSH auf den Proxmox-Host + pct exec)
| Eigenschaft |
Wert |
| Hostname |
Vaultwarden |
| Container-ID (VMID) |
111 |
| Proxmox-Node |
proxmox (192.168.2.230) |
| Rolle |
Vaultwarden — selbst-gehosteter Bitwarden-kompatibler Passwort-Manager-Server |
| IP-Adresse |
192.168.2.241 (DHCP, /24) |
| Root-Storage |
Storage:111/vm-111-disk-0.raw (NFS-Storage "Storage"), 8 GB |
Kritischer Dienst: Da hier vermutlich Passwörter/Zugangsdaten für andere Systeme verwaltet werden, sind Verfügbarkeit und Backup-Sicherheit dieses Containers besonders wichtig.
| Eigenschaft |
Wert |
| Architektur |
amd64 |
| CPU-Kerne (Limit) |
2 |
| RAM-Limit |
2048 MB |
| Swap-Limit |
512 MB |
| Netzwerk |
eth0, Bridge vmbr0, Firewall aktiv, MAC BC:24:11:1A:A8:46, DHCP |
| Features |
nesting=1 |
| Unprivileged |
ja |
| Storage-Besonderheit |
Root-Disk liegt auf dem NFS-Storage "Storage" |
- Kein Backup gefunden (weder automatisiert noch manuell im Storage
Backup).
- Keine Snapshots vorhanden.
- OS: Debian GNU/Linux 13 (trixie)
- Kernel:
7.0.12-1-pve (Proxmox-Host-Kernel)
- Uptime (Container): ca. 5 Wochen, 2 Tage
- Root-Dateisystem korrekt
rw gemountet, kein Read-Only-Problem.
| Ressource |
Wert |
| CPU-Kerne |
2 |
| RAM |
2,0 GiB (davon ~129 MiB belegt) |
| Root-Disk |
7,8 GB gesamt, 1,9 GB belegt (26 %), ext4 |
- Interface:
eth0, MAC BC:24:11:1A:A8:46, IP 192.168.2.241/24, DHCP
| Port |
Protokoll |
Dienst |
| 22 |
TCP |
SSH |
| 25 |
TCP (nur localhost) |
Postfix (lokal) |
| 80 |
TCP |
Vaultwarden Web-UI/API — nur HTTP, kein TLS |
| Eigenschaft |
Wert |
| Image |
vaultwarden/server:latest |
| Container-Name |
vaultwarden |
| Port |
80 (HTTP, unverschlüsselt) |
| Daten-Verzeichnis |
Bind-Mount /root/docker/vaultwarden/vw-data (Host) → /data (Container) |
| Restart-Policy |
unless-stopped (am 2026-08-05 von no auf unless-stopped korrigiert) |
| Läuft seit |
4 Tage (Stand Erhebung — deutlich kürzer als der Container-Uptime von 5 Wochen, d. h. wurde zwischenzeitlich manuell neu gestartet oder aktualisiert) |
| Konfiguration |
über Umgebungsvariablen (ROCKET_ADDRESS=0.0.0.0, ROCKET_PORT=80) |
- Kein projektspezifischer Cron-Job gefunden.
- Kein Reverse Proxy/TLS im Container selbst erkennbar — falls kein vorgeschalteter TLS-Terminator (z. B. Nginx Proxy Manager auf LXC 102) genutzt wird, läuft der Zugriff aktuell unverschlüsselt.
Restart-Policy korrigieren — Erledigt am 2026-08-05: docker update --restart unless-stopped vaultwarden, verifiziert.- TLS/externe Erreichbarkeit — geklärt: Vaultwarden ist extern über Nginx Proxy Manager (LXC 102) unter
vaultwarden.kindergurke.de mit gültigem Let's-Encrypt-Zertifikat, Force SSL und HSTS eingerichtet (Config: /data/compose/1/data/nginx/proxy_host/6.conf auf LXC 102). Extern also durchgehend verschlüsselt — kein Handlungsbedarf. Internes HTTP (Port 80, 0.0.0.0 gebunden) bleibt bewusst so belassen (Nutzer-Entscheidung vom 2026-08-05); optionale Härtung wäre eine Proxmox-Firewall-Regel, die Port 80 nur von der NPM-IP (192.168.2.231) erlaubt.
- Backup-Strategie einrichten (hohe Priorität, als Nächstes geplant): Kein Backup vorhanden.
/root/docker/vaultwarden/vw-data enthält die verschlüsselte Passwort-Datenbank — Verlust wäre gravierend. Nutzer plant, dafür einen Proxmox Backup Server (PBS) aufzusetzen, um Backups für alle LXCs/VMs zu automatisieren.
- Grund für kurzen Container-Uptime (4 Tage) vs. LXC-Uptime (5 Wochen): deutete auf einen kürzlichen manuellen Neustart oder Absturz hin — durch die jetzt korrigierte Restart-Policy künftig weniger relevant.