General architecture — objective, topology, who does what
Extracted from the master document on 2026-09-04. §N numbering preserved so as not to break cross-references.
1. Objective and principles
Section titled “1. Objective and principles”BalserosWorld is a home virtualization and self-hosting environment oriented toward hands-on learning of Proxmox VE/KVM, Debian, Docker and Compose, IP networking and Docker virtual networks, DNS, TLS, reverse proxy, remote access, monitoring, storage, backup automation and disaster recovery. The main rule is to understand, validate and document every change.
| Principle | Practical consequence |
|---|---|
| Proxmox stays clean | No Docker workload on the hypervisor |
| Services are isolated in VMs | VM 100 = services, VM 101 = backups |
Administration with balsero + sudo |
root only for recovery |
| SSH by key | PasswordAuthentication no, PermitRootLogin no |
| Secrets out of Git and out of the documentation | .env with chmod 600, .gitignore |
| Persistence decoupled from the container | The container is recreatable; the data is not |
| Administrative panels are not published by default | Tunnel off unless needed |
| A backup is not tested until you restore it | Part IX is what decides, not Part VIII |
2. Topology
Section titled “2. Topology” Internet │ ┌──────────────┴──────────────┐ │ │ Cloudflare DNS Cloudflare Tunnel names + DNS-01 TLS selective publishing │ │ └──────────────┬──────────────┘ ▼ LAN 192.168.2.0/24 │ ┌────────────┴────────────┐ │ │ Proxmox pve VM 100 docker-host 192.168.2.200 192.168.2.8 │ Docker │ shared `proxy` network 172.22.0.0/16 │ ┌──────────┬──────────┼───────────┐ ▼ ▼ ▼ ▼ Caddy Vaultwarden Kuma Portainer │ └──────────────► Nextcloud AIO (host.docker.internal:11000) │ physical 1 TB HDD /mnt/storage
VM 101 backup-manager 192.168.2.10 │ Borg repository (/home/borg/repo, own disk 150G) │ rclone crypt │ Cloudflare R2
Private administration:Windows / Android ── Tailscale ──► pve / docker-host / backup-manager3. Responsibility map — who does what
Section titled “3. Responsibility map — who does what”Four pieces are constantly confused because all four “give access”. They are not substitutes for each other; each one answers a different question:
| Piece | Question it answers | What it does NOT do |
|---|---|---|
| Cloudflare DNS | Which IP corresponds to this name? | It does not provide connectivity nor route anything |
| IP routing / LAN / Tailscale | By which path do I reach that IP? | It knows nothing about HTTP or service names |
| Caddy | Given this HTTP hostname, which backend serves it? | It is not an IP routing table |
| Docker DNS (127.0.0.11) | Which IP does container X have right now? |
Only inside user-defined Docker networks |
| Cloudflare Tunnel | How do I publish this without opening ports? | It is not administration; it stays off |
| Tailscale | How do I administer this privately? | It does not terminate TLS nor do reverse proxy |
LAYER PIECE TRANSLATES / DECIDES ───────────────────────────────────────────────────────────────── name → Cloudflare DNS vault.balserosworld.net → 192.168.2.8 network → LAN / Tailscale how to reach 192.168.2.8 HTTP → Caddy hostname → reverse_proxy <backend> docker → Docker DNS vaultwarden → 172.22.0.x app → Vaultwarden method + path → internal handler