Two hosts in the fleet are deliberately not Proxmox VMs on hot-bm-nl — standalone Hostkey VPSes, each reached over its own dedicated WireGuard tunnel. Same reasoning as Vaultwarden's Gateway placement: kept off bare metal so a future Proxmox/bare-metal outage can't take them down too.
Hostkey NL, vm.v2-nano (2 vCPU / 4 GB RAM / 60 GB NVMe). Runs ERPNext v16 (erp.dickson-supplies.com, plus a Tor onion mirror).
Real gotchas specific to this stack:
bench serve — gunicorn --workers=2 --worker-class=gthread --threads=4 --timeout=120 wsgi:applicationinit: true is required on the backend container — without it, tini doesn't reap orphaned healthcheck-spawned curl processes, the PID limit fills, and the container becomes unkillabledocker stop/maintenance, the stack stays down (unless-stopped doesn't restart a manually-stopped container) — always follow with docker compose up -ddickson-worker can get permanently stuck crash-looping after a host reboot — the base image's entrypoint does a naive rm -rf+ln -s against what's actually a named-volume mountpoint. Fix: docker compose up -d --force-recreate dickson-worker, not a plain restartbench build inside the container — it invalidates asset hashes that get lost on the next restart; asset rebuilding is handled automatically by a startup script insteadHostkey CH, vm.v2-medium (8 vCPU / 16 GB RAM / 160 GB NVMe). Hosts PrivateNexus itself, its docs site, and Catalogue-deployed product-feature demos.
SSH hardening (2026-08-18): public SSH had been open to the entire internet since this box's original standup — a real oversight, not a deliberate trade-off (83,000+ failed login attempts in 7 days when found). Fixed: Tailscale installed, UFW scoped to the wg3 tunnel peer and the Tailscale CGNAT range only, public IP access closed. If reviewing any new standalone VPS host, check this specifically — it's the kind of gap that doesn't announce itself.
Catalogue deploy flow — see the PrivateNexus product docs at docs.privatenexus.net for how this works from a user's perspective. Infra-side: Catalogue-deployed containers bind to the tunnel IP (10.10.2.2:<port>) specifically, never 0.0.0.0 — Docker's own iptables rules are known to bypass UFW for published ports, so binding to the tunnel-specific IP means Docker's NAT never matches traffic arriving on the public IP at all, which is more robust than relying on UFW alone.
Both hosts reinforce the same lesson: a standalone VPS outside the main VLAN mesh doesn't inherit any of hot-bm-nl's or the Gateway's default protections automatically. Each one needs its own UFW policy, its own Tailscale enrollment, its own patching cadence — see Automated Patching — checked explicitly, not assumed.