# Container Strategy — SNS Networking **Entity:** SNS Networking · **Status:** Buildable now ## What it is Guidelines for when to use LXC containers vs VMs vs Docker on Proxmox, keeping things simple and predictable. ## Decision Tree ``` Need full kernel isolation or non-Linux OS? YES → VM (KVM) NO → Is it a single long-running daemon (DNS, proxy, small app)? YES → LXC container (Proxmox-native, lowest overhead) NO → Is it a multi-container app with a compose file? YES → VM running Docker + Compose NO → LXC container ``` ## Rules 1. **LXC is default** for single-service workloads. Lower RAM, faster boot, native Proxmox backup/snapshot support. 2. **Docker inside a VM** (not inside LXC) when the app ships as a compose stack. Avoids the nested-container headaches of Docker-in-LXC. 3. **No Kubernetes.** Not until there are 20+ services that need orchestration and auto-scaling. The ceiling is named; the upgrade path is k3s on dedicated VMs. 4. **One service per container/VM.** No multi-app VMs except dev/test throwaway boxes. 5. **Naming:** `{service}-{env}` — e.g., `gitea-prod`, `caddy-prod`, `monitoring-dev`. ## LXC Template Defaults - **OS:** Debian 12 (official Proxmox template) - **Resources:** 1 vCPU, 512MB RAM, 8GB disk (grow as needed) - **Network:** static IP on service VLAN, gateway to Caddy - **Security:** unprivileged container, nesting disabled unless Docker required ## VM Template Defaults - **OS:** Debian 12 cloud-init (template ID 9000) - **Resources:** 2 vCPU, 2GB RAM, 32GB disk - **Network:** same as LXC - **Agent:** qemu-guest-agent installed for Proxmox integration ## Upgrade Path - **k3s:** When service count exceeds ~20 or you need rolling deploys, stand up 3 k3s nodes (VMs on Proxmox) and migrate Docker Compose apps to Helm charts. - **Podman:** Drop-in Docker replacement if Docker licensing ever becomes a concern (it won't for self-hosted, but Podman is rootless by default — security win).