The Whole Stack, End to End

The edge is a single FortiGate 90G pushed well past a typical home deployment. SD-WAN bonds a 2.5 GbE fiber primary with a 1 GbE cable backup in the wan-failover-link zone, where Performance SLA health probes drive both automatic failover and application-aware steering. When configured for it, SD-WAN also spreads sessions across both links at once by bandwidth ratio for aggregate throughput.

On the application side, a Virtual Server offloads SSL and load-balances across a health-checked nginx pool, while Full SSL Inspection acts as a controlled man-in-the-middle: the FortiGate terminates two TLS sessions, re-signing to managed clients with its own CKEL_ROOT_CA while validating each origin's real certificate. That decrypted stream is what makes Layer-7 filtering possible. Application control, web filtering, IPS, antivirus, DNS filtering and DLP all inspect the payload in the clear before it is re-encrypted and a single policy verdict is applied. The notable part is doing all of this at 2.5 Gbps symmetric with inspection fully enabled.

The compute layer is a nine-node Proxmox VE cluster spanning everything from an EPYC server to small-form-factor boxes, tied together with Corosync quorum and HA so guests live-migrate and restart automatically when a node drops. Storage is ZFS end to end. NVMe mirrors and RAIDz2 pools run compression and scheduled scrubs, and their snapshots feed both replication between nodes and the backup chain.

For workloads that need real hardware, VFIO passthrough isolates a GPU's IOMMU group, binds it to vfio-pci, and hands it straight into a q35/OVMF guest, so a full RTX 4090 runs inside a VM at close to bare-metal speed as a dedicated inference node.

The Arch daily driver runs btrfs with a flat subvolume layout, and snapper keeps an automated ~30-day window of local snapshots. Pre/post-pacman and timeline snapshots make a bad upgrade a one-command rollback. A systemd-timed restic job then takes encrypted, file-level copies of /home and /data to a Synology NAS, which HyperBackup mirrors offsite to Wasabi.

The Proxmox cluster leans on Proxmox Backup Server for incremental, deduplicated, client-encrypted guest backups, with ZFS replication between nodes for warm standby; PBS and the offsite cloud PVE node both sync to Wasabi. The Hyper-V lab uses Veeam for application-consistent full image backups daily plus incrementals, kept hot locally for ~45 days before older restore points age out to a Wasabi capacity tier.

Privacy is non-negotiable: restic and Veeam encrypt client-side, so keys never leave the host and only ciphertext crosses the wire. Wasabi adds its own encryption at rest and stores everything deduplicated. The provider never holds a key or sees plaintext.

CUDA reaches workloads through three deployment paths: native execution on the Arch desktop, a VFIO passthrough guest with its own GPU driver, or containers with the NVIDIA Container Toolkit. PyTorch, vLLM, SGLang, and ComfyUI use the GPU through the software environment configured for each workload. Moving a workload still requires compatible drivers, dependencies, and GPU support.

The RTX 5090, RTX 4090, and two-node DGX Spark cluster are my primary daily compute systems. The smaller cards support lighter inference, testing, and CI. I allocate work around model memory requirements and available capacity; concurrent jobs still compete for the same physical GPU resources. AMD and integrated GPUs handle work outside the CUDA stack.

A Proxmox passthrough VM receives a physical GPU through vfio-pci and runs the NVIDIA driver inside the guest. Docker and the NVIDIA Container Toolkit then expose that GPU to selected containers. The same container pattern works directly on the Arch host for native GPU workloads.

The kernel driver stays on the container host, whether that host is a VM or a physical machine. Images carry application dependencies and their required CUDA runtime, while the toolkit provides device access and driver integration. Containers separate software environments; GPU memory and compute still need capacity planning.

Security runs as a distributed CrowdSec deployment: log processors across the hosts and edge parse logs and ship alerts to a central LAPI, a Postgres-backed, LAPI-only Security Engine that is the single source of truth, while bouncers query it for decisions. Because the processors don't talk to each other, the central API is what makes a detection on one box actionable everywhere, and all of that traffic stays on Tailscale.

The engine's full decision union (local bans plus the CAPI community feed and console lists, around 75k entries) is mirrored on the public thallium box and served as a plaintext list at threat.cktechnology.io/crowdsec.txt, which the FortiGate pulls in as an external threat feed and enforces with a DENY policy. An attack on the public Azure website is reported by its bouncer, lands in the feed, and is blocked at the perimeter for every other service, closing the detection-to-enforcement loop. DNS is just as deliberate: Technitium and Pi-hole both front a validating Unbound resolver, with FortiGate SD-WAN failing over between them so name resolution survives a resolver going down.