WarGreymon

1. SFP+ 1 → Switch SFP+ 1 (10GbE, primary trunk). Optionally also connect em0 → Switch port 1 (1GbE fallback) — not required to boot, but handy from day one.
2. em1 (WAN) → home router, using whatever cable is already running to your router.
3. Power via PDU outlet, label PDU-3-OPN.
4. Press power. Wait 30–60 seconds for boot — you'll see console text if a monitor is attached, or just wait if not.
5. Default login is root / opnsense. Log in once, then immediately go set a real password — don't leave this step for later.

• Power LED solid, no error beeps
• em1 shows link (WAN cable seated)
• Logged in once with default credentials and changed the password

1. SSH in: ssh admin@10.0.1.1 (or use the console if SSH isn't enabled yet).
2. Run ip link show and look for the interface reporting a 10000 Mbps link once the SFP+ cable is seated — that's your target.
3. In the web UI: System → Interfaces → Assignments → add that identified port as LAN.

ssh admin@10.0.1.1
ip link show
# look for the interface reporting 10000 Mbps

• Correct 10GbE interface identified (not guessed)
• Assigned as LAN in System → Interfaces → Assignments

1. Static IPv4: 10.0.1.1, prefix /24.
2. Enable DHCP on this interface: range 10.0.1.100–200.
3. Leave em0 configured too, as a secondary/fallback VLAN parent — this is what you manually switch to if the 10GbE link ever fails.

• LAN shows 10.0.1.1/24, interface up
• Can ping 10.0.1.1 from an admin PC
• https://10.0.1.1 loads the web UI

1. Go to Interfaces → Other Types → VLAN, click add.
2. Parent interface: LAN (the SFP+ trunk from Step 3). VLAN tag: the VLAN number (10, 15, 20…). Description: the VLAN's name.
3. Go to Interfaces → Assignments, add the new VLAN as a real interface.
4. Open that interface, set static 10.0.X.1/24, enable DHCP 10.0.X.100–200.
5. Repeat for all 15: 10, 15, 20, 25, 30, 35, 40, 45, 50, 60, 70, 80, 90, 100, 999.

• All 15 VLAN interfaces created and visible under Interfaces → Assignments
• All show GREEN (up) status
• Each has the correct 10.0.X.1 gateway and DHCP range

Rule order per VLAN (first match wins, catch-all deny always last):

10 Management  → ANY                 (allow)
20 Media       → 30 Cloud, 80 DB, WAN (allow)
30 Cloud       → 80 DB, WAN           (allow)
35 Trading     → 60 DNS, WAN (broker) (allow — outbound only, no lateral VLAN access)
40 Photos      → 40 self, 60 DNS only (allow)
45 Cameras     → nothing, not even DNS   (isolated — Frigate reaches it via a dedicated NIC, not routing)
50 Monitor     → ANY                 (allow)
60 DNS         → ANY                 (allow, UDP/53)
70 VPN         → ANY                 (allow)
80 Database    → 60 DNS only         (allow)
90 Testing     → ANY                 (allow)
999 NAS        → nothing outbound    (isolated)
*  → *                               (BLOCK — catch-all)

Add outbound NAT for internet-needing VLANs (15, 20, 30, 35, 50, 70, 90) under Firewall → NAT → Outbound. VLAN 35 (Trading) should be restricted to just the broker's IP ranges/hostnames if your firewall supports FQDN aliases — not a blanket internet allow.

• Allow rules created per VLAN, in the order above
• Catch-all BLOCK rule sits at the bottom of every VLAN's rule list
• Outbound NAT configured for 20, 30, 50, 70, 90

1. Ping each VLAN gateway (10.0.X.1) and confirm DHCP hands out an address on each.
2. Test one allowed path (e.g. 20→30) and one blocked path (e.g. 40→internet) against the matrix in Section 05.
3. Change the default password if you haven't, disable Telnet, force HTTPS-only, enable logging.
4. Back up config: System → Configuration → Backup & Restore → download XML, store it off-box (in the GitHub repo's /archive or a password manager, not just on the NAS).

• All 14 gateways reachable, DHCP confirmed on at least 3 spot-checked VLANs
• One allow + one block tested and behaved as expected
• Config XML backed up off-box

1. Disable UPnP and NAT-PMP on OPNsense entirely. Both protocols allow any device on the network to open an inbound port mapping without administrator approval, and were the root cause of the DeadBolt ransomware campaign against roughly 19,000 QNAP NAS devices via auto-forwarded UPnP mappings.
2. Add an outbound firewall rule referencing a maintained threat-intelligence block list (Spamhaus DROP is a standard choice) as a destination alias. This does not affect legitimate traffic; its function is to prevent a compromised host from reaching a known command-and-control address if one is ever compromised regardless of the inbound protections in place.
3. Optionally, enable GeoIP filtering on the WAN interface. This reduces log noise from high-volume scanning sources and is a genuine additional layer, though it does not stop a determined attacker routing through infrastructure inside an allowed country.

The wildcard certificate configured in Section 07 → Group B → Proxy & dashboard has a secondary benefit here: a wildcard entry in Certificate Transparency logs discloses that *.yourdomain.com exists, but does not enumerate individual subdomains the way a separate certificate per service would. This is a reason to prefer one wildcard certificate over per-service certificates beyond the operational convenience already described there.

• UPnP and NAT-PMP disabled
• Outbound block list rule active, referencing a maintained threat-intelligence feed
• GeoIP filtering considered and a decision made, whether enabled or not (optional)

ssh admin@10.0.1.5 (or console)

/interface/ethernet set sfp-sfpplus1 disabled=no
/interface/ethernet set sfp-sfpplus2 disabled=no

/interface ethernet print
# confirm both show speed=10Gbps once cables are seated

• Both SFP+ ports enabled
• Both show 10Gbps once DAC cables are seated on both ends

/interface/bridge/port/add bridge=vlan-trunk interface=sfp-sfpplus1
/interface/bridge/port/add bridge=vlan-trunk interface=sfp-sfpplus2

/interface/bridge/vlan/print
# both SFP+ ports should show all 15 VLAN IDs tagged

• Both SFP+ ports added to the trunk bridge
• bridge/vlan/print shows all 15 VLAN IDs tagged on both

1. ether1 — trunk, all 15 VLANs, → OPNsense em0 (1GbE fallback)
2. ether3 — trunk, all 15 VLANs, → Proxmox eth0 (1GbE fallback)
3. ether4 — access, untagged VLAN 30, → NAS NIC1
4. ether5 — access, untagged VLAN 10, → NAS NIC2
5. ether2 — access, untagged VLAN 10, → admin laptop drop (leave patched through to wherever you'll sit)
6. ether6 — access, untagged VLAN 10, → NanoKVM

• ether1 & ether3 confirmed trunk mode
• ether4/5/2/6 confirmed access mode with correct untagged VLAN

1. Remove VLAN 1 from the allowed-VLAN list on both trunk ports (SFP+1, SFP+2, ether1, ether3).
2. Set the switch's own management interface to VLAN 10 explicitly (already done in Step 3) rather than leaving it on VLAN 1 by default.
3. Where the platform allows it, set an explicit native VLAN on trunk ports rather than leaving VLAN 1 as the implicit native — or disable native/untagged VLAN handling on trunks entirely if RouterOS supports it.

• VLAN 1 removed from both trunk ports' allowed lists
• A misconfigured/factory-reset port would now fail to pass traffic rather than silently landing on a working default

/interface ethernet print
# sfp-sfpplus1, sfp-sfpplus2, ether1-6
# should all show "R" (running)

• All expected ports show running ("R")
• Unused ports (7, 8) left disabled or unassigned

1. Flash the Proxmox VE ISO (version 9.2, built on Debian 13 "Trixie," current as of this writing — confirm the latest point release on the official downloads page before installing) to a USB stick.
2. Boot the MS-01 from USB, install to the 2TB NVMe drive.
3. First login: https://<ip>:8006 in a browser, accept the self-signed certificate warning.

• Proxmox installed, web UI reachable on port 8006

1. Review the script's contents before running it — this applies to any script executed with root privileges from a third-party source, not a specific concern about this one.
2. Run it from the Proxmox host shell: bash -c "$(wget -qLO - https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/tools/pve/post-pve-install.sh)"
3. Select the no-subscription repository when prompted; the enterprise repository prompt can be declined unless a paid subscription is in use.

• No-subscription repository active, apt update runs without repository errors

The trust model is the same as any script executed with root privileges from a source not personally authored: the community-scripts organisation is the maintained successor to the original tteck repository, scripts are open source and reviewable before execution, and the general precaution in Step 1b — read a script before running it — applies uniformly across every application deployed this way in this document, not as a repeated caveat per service.

• Helper-Scripts site bookmarked as the first check before manually scripting a new LXC deployment

auto enp2s0f0
iface enp2s0f0 inet manual

auto vmbr0
iface vmbr0 inet manual
    bridge-ports enp2s0f0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 10,15,20,25,30,35,40,45,50,60,70,80,90,100,999

Apply with systemctl restart networking. Keep eth0 (the 1GbE fallback NIC) as a separate manual bridge you're not actively using, ready if the 10GbE link ever needs replacing.

• vmbr0 created, VLAN-aware, all 15 VLAN IDs listed
• Networking restarted without errors, SSH/web UI still reachable

Single VLAN-aware vmbr0, tag per VM in Hardware → Network Device → VLAN Tag. Jellyfin VM → 20, Nextcloud → 30, Postgres → 80, and so on per the VLAN table in Section 05.

• Every VM's NIC has an explicit VLAN tag set (never left blank/untagged)
• vmbr0 itself carries no VLAN tag of its own — only individual VM NICs are tagged

Prerequisite: the NAS (Group A → Tab 3) must already be configured with its shares created before this step — this is why NAS precedes Proxmox in the tab order.

Datacenter → Storage → Add → NFS: server = NAS IP on VLAN 30, export = the share path from the NAS tab, content = Disk image / ISO / backup as needed.

• NFS storage added and shows green/active in Datacenter → Storage
• Throughput spot-checked (>100MB/s target on the 1GbE NAS link)

1. Create a small VM (any lightweight Linux ISO works), tag its NIC VLAN 90 (Testing).
2. Confirm it gets a DHCP lease from 10.0.90.100–200, and can ping its gateway 10.0.90.1.
3. Confirm reachability matches the traffic matrix in Section 05 — it should reach the NAS if a rule allows it, and should not reach VLAN 40 (Photos).

• Test VM gets correct DHCP lease and gateway
• Allowed path confirmed, blocked path confirmed blocked

This design uses the Terramaster appliance because the hardware was already owned at the point the network design began, and the appliance model trades some of ZFS's data-integrity guarantees for a simpler, faster initial setup. A TrueNAS deployment would require different hardware — a generic x86 host with sufficient SATA/NVMe connectivity, no Terramaster-specific components — and is noted here as an alternative rather than a planned change.

• Confirmed: this device runs TOS, and TrueNAS-specific instructions found elsewhere do not apply directly

1. Install all four drives into the bays.
2. NIC1 → switch port 4 (VLAN 30), NIC2 → switch port 5 (VLAN 10).
3. Complete initial setup via the management VLAN, using TerraMaster's discovery tool (TNAS PC/Mac, or the web-based discovery page) to locate the device's assigned address.
4. Apply any pending TOS firmware update before creating the storage pool — a fresh appliance from stock may be several point releases behind.

• All four drives detected in the storage manager
• Both NICs show link, on the correct VLANs
• TOS updated to the current version before proceeding

1. Storage Manager → create a RAID 5 array across the four bays. Approximately 4TB usable after parity overhead.
2. Enable S.M.A.R.T. monitoring and a weekly scheduled scan.
3. Enable TOS's own scheduled RAID scrub/data-integrity check if the model supports it, as a partial substitute for ZFS's continuous checksumming.

• RAID 5 array created, initial resync started
• S.M.A.R.T. monitoring enabled with a weekly scan scheduled
• Scheduled scrub/integrity check enabled if available

1. Create shares: /storage, /backups, /media.
2. Enable NFS, with the export scoped to the relevant VLAN subnets specifically — not an unrestricted "any" export.
3. Create per-service scoped accounts rather than a single shared administrative login for every service that accesses the NAS.

• Shares created and exported
• NFS export restricted by subnet, not open to "any"
• Scoped accounts created; no shared administrative login in use by any service

1. Enable scheduled snapshots on the shares created in Step 4 — a daily snapshot with a one- to two-week retention window is a reasonable starting point.
2. Confirm the snapshot schedule does not depend on the RAID array being otherwise idle, and that it does not conflict with backup job timing (Section 07 → Group B → Backups).

• Scheduled snapshots enabled on primary shares
• Retention window set and confirmed not to fill available capacity

From Proxmox: ping 10.0.30.10 and ping 10.0.1.100. Disconnect each cable in turn to confirm the NAS remains reachable on the other NIC before relying on this configuration for redundancy.

• Both NICs individually confirmed reachable

1. HDMI-in ← Proxmox HDMI-out.
2. USB-C (device emulation) ← Proxmox USB port.
3. Ethernet → switch port 6 (VLAN 10, access, untagged).
4. Aux power USB-C ← a spare USB port on Proxmox, or a small USB power adapter into a PDU-adjacent outlet if you'd rather it not depend on Proxmox's own power state.

• HDMI capture confirmed (see the Proxmox boot screen through NanoKVM)
• USB emulation confirmed (mouse cursor moves on the host from NanoKVM's web UI)
• Status LEDs normal, no error pattern

1. Power it on, wait for the status LED to settle.
2. Find its IP (check your router's DHCP client list, or use the discovery method in the quick start guide).
3. Log into the web UI, go to Settings → Check for Updates, apply if available.

• NanoKVM web UI reachable
• Firmware confirmed up to date

1. Confirm it pulled an address in the 10.0.1.100–200 range from OPNsense.
2. In OPNsense, add a DHCP static mapping (by MAC address) so it always gets the same IP.

• Static DHCP reservation configured on OPNsense
• Address noted somewhere you'll actually find it during an outage (Homarr, a sticky note, wherever — just not "I'll remember")

1. Change the default password immediately.
2. Enable HTTPS on the NanoKVM web UI if not already on.
3. Disable SSH unless you specifically need it (Settings → Devices → SSH, per the user guide).

• Default password changed
• HTTPS enabled
• SSH disabled unless actively needed

1. Check whether the MS-01 exposes an accessible power/reset header (open the case, check Minisforum documentation, or search the model number plus "ATX header").
2. If yes: wire the NanoKVM-B breakout board per Sipeed's wiring diagram.
3. If no: skip this — you still have full video + keyboard/mouse. For hard power-cycling, a UPS-controlled smart outlet is the practical fallback.

• Verified whether MS-01 exposes ATX header pins before buying/wiring anything
• If wired: power on/off/reset tested remotely at least once

1. Confirm no port-forward exists on OPNsense exposing NanoKVM's port to WAN.
2. Once NetBird is deployed (Services tab), scope access so only your "admin" peer group can reach VLAN 10 where NanoKVM lives.

• No WAN port-forward to NanoKVM exists
• Reachable only via NetBird admin group once that's deployed

1. Set a BIOS/UEFI admin password on the MS-01, stored in Vaultwarden like every other credential.
2. While in there, disable booting from any external/USB media by default, and disable any unused Thunderbolt/USB controllers not actually in use.

• BIOS password set and stored in Vaultwarden
• External boot disabled by default, unused USB/Thunderbolt controllers disabled

1. Connect the switch to power and to a temporary access-mode port on the MikroTik switch (not port 7, which is reserved for the trunk configured in Step 2).
2. Run the ProSAFE Plus Configuration Utility from a Windows PC on the same network segment, or check the switch's DHCP lease on OPNsense if it obtained one automatically.
3. Log in with the default password (password) and change it immediately — this switch does not support the account-separation model used elsewhere in this design, so the single admin password is the only credential protecting it.
4. Check for and apply any available firmware update before proceeding; this hardware model dates to 2012 and a specific unit's firmware history is unknown until checked.

• Switch located and reachable via the configuration utility or web interface
• Default password changed
• Firmware checked and current

1. Create VLAN 10 (Management) and VLAN 100 (Home Devices) in the switch's VLAN configuration screen.
2. Set the uplink port (the port that will connect to the MikroTik switch) to tag both VLAN 10 and VLAN 100.
3. Set every other port intended for a household device to VLAN 100, untagged (PVID 100).
4. Leave the switch's own management VLAN set to VLAN 10, matching every other managed device in this design.

• VLAN 10 and VLAN 100 created
• Uplink port tagging both VLANs confirmed
• Device-facing ports set to untagged VLAN 100

1. Move the uplink cable from the temporary access port used in Step 1 to MikroTik port 7.
2. On the MikroTik switch, confirm port 7 is configured as a trunk carrying VLAN 10 and VLAN 100 only — not every VLAN, since this switch has no reason to see lab traffic.
3. Confirm the switch's management IP (VLAN 10) is reachable from an admin device, and that a test device plugged into a VLAN 100 port receives a DHCP lease from OPNsense in the 10.0.100.0/24 range.

• Port 7 confirmed as a two-VLAN trunk, not an all-VLANs trunk
• Switch management IP reachable on VLAN 10
• Test device on VLAN 100 receives a DHCP lease and reaches the internet

1. Set one spare port (port 24, the last physical port) to untagged VLAN 10, separate from the VLAN 100 access ports used for household devices.
2. Label this port physically and in the switch's own port naming, since a household device plugged in here by mistake would receive a management-network address instead of an internet-only one.
3. Confirm a laptop plugged into port 24 receives a VLAN 10 address from OPNsense and can reach lab services — the same reach as the standing Management-VLAN exception already applied everywhere else in this design, not a new or broader rule.

• Port 24 set to untagged VLAN 10, clearly labelled
• Confirmed a device on this port receives a VLAN 10 address and reaches lab services
• Confirmed the remaining household-device ports are unaffected — still VLAN 100 only

1. Create the VLAN 100 interface on OPNsense (10.0.100.1/24), following the same procedure as every other VLAN in Section 07 → OPNsense, Step 4.
2. Allow rule: VLAN 100 → Technitium (port 53) and → WAN, matching the DNS-enforcement pattern in Section 07 → Services → Monitoring & DNS.
3. Explicit deny: VLAN 100 → every other VLAN. No exception rules — this VLAN has no legitimate reason to reach lab services.
4. Confirm Suricata and CrowdSec (Section 07 → Group C → Security & identity), already inspecting all inter-VLAN and WAN-bound traffic, cover this VLAN without additional configuration — they operate on the trunk, not per-VLAN.

• VLAN 100 interface created, DHCP enabled
• Outbound allowed only to Technitium and WAN
• Explicit deny confirmed against every lab VLAN, tested from a device on VLAN 100

1. Configure a WireGuard client instance on OPNsense connecting to a chosen VPN provider's endpoint.
2. Create a gateway using that WireGuard interface, and a policy-based routing rule scoped to VLAN 100 only, directing its traffic through that gateway instead of the default WAN gateway.
3. Verify with an IP-address check site from a VLAN 100 device that egress traffic shows the VPN provider's address, and confirm DNS continues resolving through Technitium rather than leaking to the VPN provider's own resolver.

• Not configured by default — optional, add only if outbound privacy routing for household devices specifically is wanted
• If configured: egress IP and DNS resolution both verified from a VLAN 100 device

This also sidesteps the classic reason people reach for a hosted mesh tool in the first place: a bare WireGuard server normally needs an inbound port forwarded on the router, which doesn't work at all behind carrier-grade NAT (CGNAT). NetBird's peers connect outbound to the coordination server and punch through NAT from there — no inbound port needed, which is also exactly why this build has zero port-forwards (Section 08).

Twingate, for context: a legitimate free-for-small-teams zero-trust option, but its control plane is Twingate's cloud — same category concern as Entra ID in Section 11. NetBird's self-hosted coordination server keeps that layer under this lab's own control instead, which is the deciding factor here, not a feature gap in Twingate itself.

1. Create an LXC/VM on VLAN 70 (VPN).
2. Follow NetBird's Docker Compose self-hosted quickstart to stand up the management server, signal server, and dashboard.
3. Point a DNS name at it via NGINX Proxy Manager once that's deployed (Tab B), or access by IP for now.

• NetBird management dashboard reachable and logged in

1. OPNsense: install via the OPNsense NetBird plugin (os-netbird) — a native FreeBSD package, not Docker.
2. Docker-hosted peers (any Docker host on VLAN 15, e.g. the Talos/AI/media hosts): run NetBird as a container using the netbirdio/netbird image with network_mode: host — this lets it create the WireGuard interface (wt0) directly on the host's network stack rather than isolated inside Docker's bridge network. Mount /etc/netbird and /var/lib/netbird as volumes so the peer's identity survives a container restart.
3. Admin laptop/phone: native NetBird client from the official download page.
4. Authenticate each against the self-hosted dashboard, confirm each shows "Connected" in the peers list.

# Docker-hosted peer example
docker run -d --name netbird \
  --network host \
  --cap-add NET_ADMIN \
  -v /etc/netbird:/etc/netbird \
  -v /var/lib/netbird:/var/lib/netbird \
  --restart unless-stopped \
  netbirdio/netbird

• OPNsense enrolled and connected (via the OPNsense plugin)
• Proxmox / Docker hosts enrolled and connected (via the Docker container, wt0 interface confirmed with ip a)
• Admin devices enrolled and connected

1. Create an admin group containing your own admin devices, with access rules to VLAN 10 + VLAN 90.
2. Create a second, narrower personal-devices group for your phone (and any future phone/tablet), with access rules to VLAN 30 (Cloud) + VLAN 40 (Photos) only — everything it needs for Nextcloud, Vaultwarden, and Immich backup, nothing it doesn't.
3. Leave other VLANs unreachable via NetBird by default — add exceptions deliberately, not by accident.

• Admin group created, scoped to management + testing only
• personal-devices group created, scoped to Cloud + Photos only
• No blanket "allow all" access rule left in place

Configure an OIDC identity provider (many free options work fine for a single-user homelab) instead of relying on local username/password login alone.

• SSO/OIDC or 2FA enabled on the NetBird dashboard login

1. Register a domain (or use one you already own) and add it to a free Cloudflare account.
2. Deploy cloudflared as a container on VLAN 10, authenticate it to your Cloudflare account.
3. Create a tunnel and add public hostnames that map to internal services through NPM/Traefik, e.g. jellyfin.yourdomain.com → 10.0.10.x:443.

• cloudflared deployed on VLAN 10, tunnel shows healthy in the Cloudflare dashboard
• At least one service reachable through the tunnel from outside the home network

In the Cloudflare Zero Trust dashboard, create an Access application per exposed hostname, require authentication (email OTP is the simplest starting point), and scope each policy to just yourself unless you specifically intend to share access.

• Access application created for each exposed hostname
• Policy tested — an unauthenticated request is challenged, not served directly

1. In each Access policy, add a country rule scoped to Australia (adjust temporarily if travelling).
2. Enable Cloudflare's rate limiting / bot protection on the Access login page.
3. Apply the same logic to NetBird and OPNsense's own admin login — fail2ban (or OPNsense's built-in lockout) on repeated auth failures, not just on the Cloudflare side.

• Country-restricted Access policy in place
• Rate limiting / auto-block confirmed active on Cloudflare Access, NetBird, and OPNsense admin login

A single cloudflared replica is a fine backup path for a home lab. If this ever needs to be genuinely highly available, multiple cloudflared replicas behind Docker Swarm is a documented pattern — worth knowing exists, not worth building until the single-replica version has actually let you down.

1. Deploy as an LXC on VLAN 10.
2. Only forward ports 80/443 to it from OPNsense for whatever you actually intend to expose externally — internal-only services don't need a WAN forward at all.

• NPM deployed, admin UI reachable

1. Add a proxy host per service: domain name → internal IP:port.
2. Issue one wildcard certificate (*.yourdomain.com) via Let's Encrypt DNS challenge, and reuse it across every proxy host in NPM — this is the same domain and certificate strategy used for NetBird/Cloudflare Access below, so the whole lab shares one consistent chain of trust.
3. Confirm auto-renewal is actually configured, not a one-off manual issue.

• At least one service reachable via a clean HTTPS name, no port in the URL
• Wildcard certificate issued once and reused across services, renewing automatically

Deploy as an LXC/container, add links to every service, set as your browser home page.

• Homarr deployed with at least the core services linked

Alternative worth knowing: Homepage is configured almost exactly like Traefik — YAML/labels, not a GUI — which makes it genuinely simpler than Homarr if every service is already a pure Docker Compose stack. Homarr's GUI-first setup is why it's the default here; swap later if label-driven config starts feeling more natural than clicking.

Connect Homarr's integrations to Proxmox, Jellyfin, and your download clients for live status/stats directly on the dashboard, not just static links.

• At least one live-status widget working (e.g. Proxmox resource usage)

1. Deploy Watchtower (or Dockcheck) as a container with access to the Docker socket, scoped to check on a daily or weekly schedule.
2. Exclude anything you'd rather update manually and review first (databases are a common exclusion — a surprise major-version bump is a worse outcome than a slightly stale image).

• Update checker deployed, schedule set
• Databases and anything version-sensitive explicitly excluded from auto-update

1. Deploy via the official Docker Compose project on VLAN 10.
2. Enter this build's actual inventory: the rack's devices, all 15 VLANs and their subnets, and current IP assignments — tedious once, but this is what turns it from a diagram into a live record.
3. Retire the manual Section 09 table once NetBox reflects the same information — don't maintain both.

• NetBox deployed, admin account created
• Rack, devices, VLANs, and current IPs entered

Start as a VM/LXC on the same Proxmox host, its own storage target on the NAS. Upgrade to a dedicated small box later if you add a second hypervisor node.

• PBS deployed, storage datastore pointed at NAS

Datacenter → Storage → Add → Proxmox Backup Server: enter the PBS host, datastore name, and credentials.

• PBS storage visible and green in Proxmox's Datacenter view

Daily incremental backups, weekly full verification job. Start with everything except purely-disposable test VMs.

• Daily backup job scheduled and has run successfully at least once
• Weekly verify job scheduled

Restore a test VM to a new VM ID, boot it, confirm it actually works — not just that the restore operation completed without an error.

• Restore performed and the restored VM actually boots and functions

1. Pick a destination: Backblaze B2 and Wasabi are the usual home-lab picks — S3-compatible, no egress fees on B2 up to your download volume, cheap per-GB storage.
2. Deploy Rclone as a scheduled job (cron on a small LXC, or a Proxmox scheduled task) rather than installing it ad hoc — this needs to run unattended.
3. Sync PBS's backup datastore (or just the most critical VMs/datasets, if full replication is more than the connection or budget can handle) on a nightly or weekly schedule.
4. Confirm the destination bucket is encrypted at rest and that Rclone's own encryption (rclone crypt) is layered on top if the destination provider itself isn't trusted with plaintext data.

• Offsite destination chosen and configured
• Rclone sync scheduled, not manual
• First sync completed and spot-checked — a file actually appears in the remote bucket

Deploy as a VM/LXC tagged VLAN 20, point its library at the NAS media share over the NFS mount from Proxmox (Hardware → Proxmox → Step 4).

• Jellyfin deployed, library scanning the NAS media share

Deploy tagged VLAN 25, add your indexers, this becomes the single place Sonarr/Radarr pull indexer config from instead of configuring each app separately.

• Prowlarr deployed with at least one indexer configured

Both tagged VLAN 20. Connect each to Prowlarr for indexers, and to Jellyfin so newly-downloaded media appears in the library automatically.

• Sonarr connected to Prowlarr
• Radarr connected to Prowlarr
• Both connected to Jellyfin's library

Deploy tagged VLAN 20, connect it to both Sonarr and Radarr as subtitle providers, pick your preferred subtitle languages/sources.

• Bazarr connected to Sonarr and Radarr
• At least one subtitle provider configured

Deploy tagged VLAN 20, connect it to Jellyfin (for library sync and login) and to Sonarr/Radarr (to actually place requests).

• Jellyseerr connected to Jellyfin, Sonarr, and Radarr
• One test request placed end-to-end and confirmed it reached Radarr/Sonarr

Full chain per the standard automated-Jellyfin pattern: Jellyseerr request → Radarr/Sonarr → qBittorrent → Bazarr → Jellyfin. Trigger one real request end to end and confirm it lands correctly organised, subtitled, and playable — not just that individual apps look "connected" in their settings pages.

• One item requested via Jellyseerr, downloaded, subtitled, and confirmed playable in Jellyfin

Deploy on VLAN 50, install node_exporter on Proxmox and OPNsense (or use OPNsense's built-in Telegraf/Prometheus exporter plugin), configure Prometheus's scrape targets.

• Prometheus deployed, at least one target being scraped successfully

1. Enable SNMP on the MikroTik CRS310, add the Prometheus SNMP exporter as a scrape target, alert on abnormal per-port traffic spikes.
2. Deploy Pulse alongside Prometheus/Grafana for Proxmox-specific monitoring.
3. Deploy Beszel's hub on VLAN 50, install its lightweight agent on Proxmox and each VM/LXC/Talos node worth watching.

• SNMP enabled on the switch, scraped by Prometheus (optional)
• Pulse deployed for Proxmox-specific views (optional)
• Beszel hub + agents deployed across multiple hosts (optional, most useful once the Talos cluster is live)

Add Prometheus and InfluxDB as data sources, import a community Node Exporter dashboard (search grafana.com/dashboards by ID) rather than building one from scratch on day one.

• Grafana deployed, at least one imported dashboard showing live data

1. Deploy two Technitium instances on VLAN 60 as plain Docker containers or LXCs — not inside the Talos cluster (see the callout below for why that's deliberate).
2. Give each a distinct DNS_SERVER_DOMAIN under Settings → General before clustering — e.g. dns01 and dns02 — and make sure it's set correctly on both from the start; a stale or mismatched value here is the single most common cause of clustering looking "connected" one moment and "unreachable" the next.
3. On the primary: Administration → Cluster → Initialize → New Cluster. On the secondary: Administration → Cluster → Initialize → Join Cluster, pointing at the primary's cluster URL. Without a real certificate yet, check "ignore certificate validation errors" to join.
4. Deploy Unbound (can sit alongside Technitium on the same host or its own small LXC), configure it as a pure recursive/validating resolver.
5. Point Technitium's forwarder at Unbound instead of a public DNS provider.
6. Set OPNsense's DHCP to hand out the Technitium primary as DNS server 1, secondary as DNS server 2.

Once this is solid, start giving services proper names instead of remembering IPs — grafana.lab.internal, ai.lab.internal, proxmox.lab.internal — via Technitium zones, matching the DNS-first organisation approach in Section 09.

• Distinct, correct DNS_SERVER_DOMAIN set on each node before clustering
• Technitium primary + secondary clustered and confirmed syncing (refresh the page, not just the first "Connected" flash)
• Unbound deployed, Technitium forwarding to it
• DHCP handing out both Technitium instances, secondary tested by stopping the primary briefly

1. The Cluster Domain must be a domain you don't already host authoritatively anywhere else. Don't reuse lab.internal (already this build's general service-naming domain, per Section 09) — pick something separate and purely technical, e.g. dnscluster.local.
2. Never use cluster.local specifically — that's Kubernetes' own reserved internal service-discovery suffix. This build has a Talos cluster planned (Section 08); even though Technitium isn't running inside it, a colliding domain is exactly the kind of thing that causes confusing failures months later for no obvious reason.
3. Keep the cluster domain and this build's real internal naming domain (lab.internal) conceptually separate forever — the cluster domain is plumbing between the two DNS nodes, not something you resolve services through.

• Cluster domain confirmed distinct from both lab.internal and cluster.local
• Understood: replication is one-way, primary → secondary only — administrative changes must always be made on the primary node
• Understood: Technitium's own DHCP clustering isn't supported yet — not a gap for this build, since OPNsense handles DHCP per VLAN, not Technitium

1. OPNsense: Firewall → Aliases → create a Host(s) alias Technitium_Servers containing both Technitium IPs (dns01, dns02).
2. Create a Port alias DNS_Ports = 53 (standard DNS), and a second Port alias DoH_DoT_Ports = 443, 853 (DNS-over-HTTPS / DNS-over-TLS) for use in the next step.
3. On every VLAN's rule set, add an explicit allow rule near the top: destination = Technitium_Servers, port = DNS_Ports — this is what actually lets each VLAN reach DNS at all (already reflected in the traffic matrix in Section 05).

• Technitium_Servers alias created with both IPs
• Explicit allow-to-Technitium rule confirmed present on every VLAN

1. On every VLAN except 10 (Management) and 70 (VPN), add a block rule below the Technitium-allow rule from Step 4: destination = any, port = DNS_Ports (53) — this catches any device trying to reach a DNS server that isn't Technitium.
2. Add a second block rule: destination = WAN, port 853 (DNS-over-TLS) — there's rarely a legitimate reason for a LAN device to speak DoT directly to the internet.
3. Create an alias Known_Public_DoH with the IP ranges of the most common public DoH providers (Cloudflare, Google, Quad9, NextDNS) and block outbound port 443 to that alias. This is necessarily incomplete — treat it as blocking the defaults, not every possible DoH provider.
4. Test from a client device: with a public resolver hardcoded, DNS lookups should now fail or time out, while normal browsing (through Technitium) keeps working.

• Port 53 to anywhere-but-Technitium blocked on every non-management/VPN VLAN
• Port 853 (DoT) blocked outbound to WAN
• Known_Public_DoH alias created and blocked on port 443
• Tested: a hardcoded public resolver fails from a client device on a restricted VLAN
• Secure DNS / private DNS disabled in browser and OS settings on your own devices, as defence in depth

Add a monitor per key service (Jellyfin, Nextcloud, Technitium, NPM...), point its notification channel at ntfy (Step 7) rather than Discord — one self-hosted notification path for the whole lab, not a third-party service in the alert chain.

• Uptime Kuma deployed, core services monitored, at least one notification channel configured

1. Deploy via the official Docker image on VLAN 50, alongside the rest of the monitoring stack.
2. Set NTFY_AUTH_DEFAULT_ACCESS=deny-all and create real users/tokens per topic — don't rely on an unguessable topic name as the only protection, which is a security-through-obscurity pattern this build avoids everywhere else (Section 07).
3. Put it behind NPM with the shared wildcard cert, like every other service — ntfy.yourdomain.com, not plain HTTP.
4. Install the ntfy app (F-Droid or Google Play — GrapheneOS-friendly either way) and subscribe to your topics.
5. Wire it in as the notification target for Uptime Kuma, Wazuh, the MT5 trading VM's fast-notification requirement (Section 07 → Group C → Trading), and the NUT UPS shutdown script — one app, every alert.

# quick test once it's running
curl -H "Title: Test" -H "Priority: high" \
  -d "ntfy is alive" \
  https://ntfy.yourdomain.com/lab_alerts

• ntfy deployed with deny-all default and real per-topic auth, not just an obscure topic name
• Reachable over HTTPS through NPM with the shared wildcard cert
• App installed and subscribed, test notification received
• Uptime Kuma and Wazuh both pointed at it as their notification target

1. Deploy via the community Proxmox VE Helper Script for Home Assistant OS (VM variant) — it automates what would otherwise be a manual ISO install and virtual disk setup.
2. Tag VLAN 90 (Testing) for now, per the existing VLAN table — see the note below on a dedicated IoT VLAN if your device count grows.
3. Give it real resources if you're a heavy user: 2+ cores, 4GB+ RAM. Light users can go smaller.
4. If you have Zigbee/Z-Wave/Bluetooth USB dongles, pass them through to the VM individually (Proxmox → VM → Hardware → Add → USB Device) rather than sharing a USB controller.

• Home Assistant OS VM deployed via the helper script
• Onboarding wizard completed, admin account created
• Any USB radios (Zigbee/Z-Wave/Bluetooth) passed through and detected

Two options, in order of preference: (1) enable multicast/mDNS relay on OPNsense between the relevant VLANs, or (2) give the Home Assistant VM a second virtual NIC directly on the IoT VLAN if one exists, so discovery happens locally on that segment. Start with option 1 — it's less invasive.

• Not needed yet — VLAN 90 already reaches what HA currently manages (revisit only if a dedicated IoT VLAN is added)

1. Deploy via the community Proxmox VE Helper Script for Homebridge (LXC variant — it's lightweight, doesn't need VM-level USB passthrough for most plugins).
2. Tag VLAN 90, same as Home Assistant.
3. Install plugins for your specific devices through the Homebridge web UI's plugin search.
4. Pair it to Apple Home by scanning the QR code / entering the setup code shown in the Homebridge UI.

• Homebridge LXC deployed
• At least one device plugin installed and configured
• Paired successfully in the Apple Home app

1. Install NetBird — currently via Google Play or Aurora Store (Aurora works without a Google account). It isn't on F-Droid yet on GrapheneOS as of writing; there's an open community request to add it, worth checking again later.
2. Open NetBird, enrol it against your self-hosted management server (same as the other peers in Section 07 → Group B → Remote access).
3. Add it to a new, narrower NetBird access group — personal-devices — scoped to just VLAN 30 (Cloud) and VLAN 40 (Photos), not the full admin group's reach into VLAN 10/90. A phone doesn't need to manage OPNsense.
4. Android Settings → Network & Internet → VPN → NetBird (gear icon) → enable Always-on VPN.
5. Settings → Apps → NetBird → Battery → set to Unrestricted — without this, Android's battery management will periodically kill the background connection regardless of the always-on setting.

• NetBird installed and enrolled
• personal-devices group created, scoped to VLAN 30 + 40 only
• Always-on VPN enabled, battery optimisation disabled for the app
• Connection reliability observed over several days before treating it as fully dependable

1. Install Immich from F-Droid (fully open-source build, GrapheneOS-friendly) or Google Play.
2. Log in with the server URL — since the phone is always connected via NetBird, this can be the internal VLAN 40 address; it'll resolve whether you're home or out.
3. Backup screen → select the Camera album (and Screenshots, Downloads, or anything else you want included).
4. Enable background backup, and turn off the "Wi-Fi only" restriction if you want photos backing up over mobile data too, since the whole point is the phone is already tunnelled into the lab regardless of network.
5. Settings → Apps → Immich → Battery → Unrestricted, same reasoning as NetBird.

• Immich installed, camera album selected for backup
• Background backup enabled, battery optimisation disabled
• Confirmed a photo taken today actually appears on the server without opening the app first — then repeat that check after a few days

1. Deploy Nextcloud (AIO or the official Docker image) on VLAN 30, backed by the PostgreSQL instance on VLAN 80.
2. Deploy Collabora Online alongside it (its own container — it's a separate service, not a Nextcloud plugin) and connect it via the Nextcloud admin panel's Collabora app.
3. Confirm a document actually opens and saves for in-browser editing, not just file storage.

• Nextcloud deployed, backed by PostgreSQL
• Collabora connected, a document edits and saves in-browser

Worth knowing, not building: a full self-hosted mail server (Mailcow, Mail-in-a-Box) is a real option for digital independence, but most residential ISPs block outbound port 25 and dynamic IPs get blacklisted quickly — it's a genuinely harder project than everything else in this build and not one to take on from a home connection without first confirming the ISP allows it.

CryptPad, if a specific need shows up: Collabora gives Nextcloud in-browser editing, but the server can still technically read document content. CryptPad is zero-knowledge — encrypted client-side, so even a compromised server can't read what's stored. Not worth running as a second, separate document platform for everything; worth adding later specifically for documents where that distinction actually matters (nothing in this build currently needs it).

1. Install Nextcloud and DAVx5, both from F-Droid.
2. Nextcloud app: add account with your server URL, enable auto-upload for the folders you want backed up (Downloads, Documents, Music — anything not already covered by Immich).
3. DAVx5: add an account, point it at the same Nextcloud server's CardDAV/CalDAV endpoint, let it discover your contacts and calendar collections.
4. In Android's own Contacts and Calendar apps, confirm the Nextcloud-synced account now shows up as a real sync source — this is what makes it "just work" like any other synced account on the phone.

• Nextcloud app syncing at least one folder
• DAVx5 configured, contacts and calendar visible in Android's native apps
• A test contact added on the phone confirmed to appear in Nextcloud's web UI (and vice versa)

1. Make sure the Nextcloud app is installed and logged in first (Step 3) — Seedvault backs up to any storage location exposed through Android's Storage Access Framework, and Nextcloud registers itself as one of those locations.
2. Settings → System → Backup → set the backup location to Nextcloud via the SAF picker.
3. Select which apps to include, confirm the encryption recovery code is generated, and store that code in Vaultwarden (Step 5) — without it, the backup is unrecoverable.

• Seedvault backup location set to Nextcloud
• Recovery code generated and stored in Vaultwarden, not just on the phone
• One test restore attempted (even to a spare/secondary device) to confirm the backup is actually usable

1. Install the official Bitwarden app — available on F-Droid, fully open-source.
2. On the login screen, tap the gear/settings icon and enable Self-hosted, entering your Vaultwarden server URL.
3. Log in, enable biometric unlock, and turn on Bitwarden as the phone's autofill service (Settings → Passwords & accounts, or similar depending on Android version).

• Bitwarden app pointed at the self-hosted Vaultwarden server, logged in
• Biometric unlock and autofill enabled
• Confirmed the same vault is reachable from a desktop browser too — one vault, every device

sudo apt update
sudo apt install -y nodejs npm nginx jq certbot
sudo apt install -y python3-certbot-dns-cloudflare

Docker and Docker Compose are already present from earlier steps in this design; NGINX here refers to the underlying package DockerWakeUp's setup script expects to find — NPM already provides this role for every other service, so this instance stays internal-only (see Step 3) rather than becoming a second public-facing NGINX.

• Node.js, npm, nginx, jq, certbot installed

1. Deploy on VLAN 15, alongside the other container-management tooling.
2. Clone the repository and create the working config from the supplied example.

git clone https://github.com/jelliott2021/DockerWakeUp.git
cd DockerWakeUp
cp config.json.example config.json
nano config.json

Each entry in services maps a route name to the Compose project that runs it. The route name and domain combine into the public hostname NPM forwards for — route: "gitea-test" under domain lab.internal becomes gitea-test.lab.internal.

{
  "proxyPort": 8080,
  "idleThreshold": 3600,
  "domain": "lab.internal",
  "services": [
    {
      "route": "gitea-test",
      "target": "http://localhost:3001",
      "composeDir": "/home/claude/homelabservices/gitea-test"
    }
  ]
}

• config.json created, at least one service entry defined

1. In NPM, create a proxy host for each on-demand hostname (e.g. gitea-test.lab.internal), forwarding to DockerWakeUp's internal address on port 8080 — not to the target container's own port.
2. Enable the existing wildcard certificate on the proxy host, exactly as for every other NPM-fronted service.
3. Leave DockerWakeUp's own NGINX config disabled or uninstalled — one TLS-terminating edge for the whole lab, not two.

• NPM proxy host forwards to DockerWakeUp's port, not the container's port
• Existing wildcard certificate applied — no separate Certbot instance created

1. Run the setup script and enable the service.

chmod +x setup-service.sh
./setup-service.sh
sudo systemctl enable docker-wakeup

To confirm it works: manually stop the test service (docker compose down) and request its hostname in a browser — the request should stall briefly while DockerWakeUp starts the stack, then complete once the target responds.

• docker-wakeup enabled at boot
• A manually stopped service starts on its next request and serves the page

In soranthony5/homelab-deployment-v1.0, add:

/terraform/       - VM & LXC definitions (Proxmox provider)
/ansible/         - OS-level config & hardening playbooks
/kubernetes/      - Kustomize/Helm manifests, one folder per app
/docker/          - Compose stacks for non-k8s services, one folder per app
  jellyfin/
    docker-compose.yml
    .env
    README.md
/archive/         - old planning docs (already exists)

• Folder structure created and pushed

1. Install OpenTofu (or Terraform) on your workstation or a dedicated LXC.
2. Configure the bpg/proxmox or Telmate/proxmox provider with an API token from Proxmox (not your root password).
3. Write your first resource: recreate one existing LXC (e.g. Homarr) as code, plan, then apply against a throwaway test VM ID first.

• Proxmox API token created, scoped (not root)
• One VM/LXC successfully created purely from Terraform code

1. Install Ansible on your workstation or a dedicated LXC.
2. Build an inventory file listing your hosts (pve, opn, docker hosts, etc.) grouped by role.
3. Write a baseline playbook: SSH key auth, disable password login, install common packages, apply timezone/NTP.
4. Run it against one host first, confirm idempotency (running it twice changes nothing the second time).

• Inventory file created, grouped by role
• Baseline playbook applied to at least one host, confirmed idempotent

1. Add the cloudflare/cloudflare provider to your Terraform config, authenticate with an API token scoped to just the Tunnel/Access/DNS permissions it needs.
2. Define your tunnel, its public hostnames, and Access applications/policies as Terraform resources.
3. plan, review, apply — then make your next Cloudflare change by editing code and re-applying, not by clicking in the dashboard.

• Cloudflare API token scoped (not a global key)
• At least one tunnel hostname and Access policy defined and applied via Terraform

1. Install Packer alongside Terraform and Ansible.
2. Write a Packer template that builds a minimal, patched Ubuntu image on Proxmox and converts it to a VM template.
3. Point your Terraform VM resources at that template instead of a raw ISO.

• One golden image built and confirmed usable as a Terraform VM source (optional — skip if the repo above already covers what you need)

1. Download the Talos ISO, create a VM in Proxmox (suggested start: 4 vCPU, 8GB RAM, 60GB disk, tagged VLAN 15).
2. Boot it — Talos comes up in maintenance mode with no config, listening on the API port.
3. Generate a machine config with talosctl gen config, edit it to set the single node as both controlplane and worker.
4. Apply the config, bootstrap etcd, pull down the kubeconfig.
5. Confirm with kubectl get nodes — one Ready node.

• Talos VM created and booted
• Machine config applied, cluster bootstrapped
• kubectl get nodes shows one Ready node

1. Install Argo CD into the cluster via its official manifests.
2. Point it at soranthony5/homelab-deployment-v1.0, path /kubernetes.
3. Deploy one trivial test app purely by pushing a manifest to git — confirm Argo CD picks it up without manual intervention.

• Argo CD deployed and synced to the repo
• One app deployed purely via a git push, no manual kubectl

Deploy via its official Helm chart or Argo CD manifest, expose it through a single OPNsense-forwarded port if you need external K8s ingress, or keep it internal-only.

• Traefik deployed, one test Ingress resource routing correctly

1. Deploy Longhorn via its Helm chart or Argo CD manifest.
2. Use it for stateful workloads that benefit from snapshots (databases, Argo CD itself) — not for bulk media, which stays on the NAS over NFS regardless.

• Longhorn deployed, one PVC provisioned and tested
• Understood and accepted: single-node = no cross-node resilience yet

Deploy as a VM tagged VLAN 90 (Testing), named dockertest01 per the naming convention in Section 09. Use it for anything you're not ready to commit to the GitOps repo yet.

• Flatcar VM deployed on VLAN 90, named per convention

1. Deploy Ollama as a container (VM/LXC tagged VLAN 15).
2. Pull a realistic starting model: llama3.2:3b, phi3.5, or qwen2.5:7b-q4_K_M — all usable on CPU without a long wait per response.
3. Test with a direct API call before adding a UI on top, so you know the model itself works.

• Ollama deployed, at least one small quantized model pulled and responding

ChatGPT-style web frontend for Ollama — chat history, multiple models, document upload for RAG-style question answering over your own files. Point it at the Ollama instance from Step 1, reverse-proxy it via NPM or Traefik as ai.lab.internal.

• Open WebUI deployed, connected to Ollama, reachable via a clean URL

Passthrough /dev/dri into the Ollama and Jellyfin LXCs (not full VM passthrough). Confirm with intel_gpu_top on the host that both containers can access it.

• iGPU passthrough configured on relevant LXCs
• Confirmed both Jellyfin transcoding and Ollama can use it

n8n is a self-hosted workflow automation tool with native Ollama/OpenAI-compatible nodes — a natural fit for things like "summarise new Paperless-ngx documents" or "generate a daily digest for Homarr" using your local model instead of a cloud API.

• n8n deployed (optional), one simple workflow built as a test

1. Create a VM: suggested 4 vCPU, 8GB RAM, 80GB disk, tagged VLAN 35.
2. Install Windows 10/11, apply all updates, keep Defender enabled.
3. Install MetaTrader 5 from your broker's official installer only.

• VM created on VLAN 35, confirmed no lateral access to other VLANs
• Windows fully patched, Defender active
• MT5 installed from the broker's official source

1. On OPNsense, restrict VLAN 35 outbound to: your broker's server hostnames (use FQDN aliases if supported), NTP, and DNS (VLAN 60) only.
2. Confirm no rule allows VLAN 35 to reach any other internal VLAN, including Management.
3. Admin access to this VM is RDP only, only reachable via the NetBird admin group — never a WAN port-forward.

• Outbound restricted to broker + NTP + DNS only
• No inter-VLAN rule exists for VLAN 35 in either direction except the exceptions above
• RDP reachable only via NetBird, never WAN-exposed

1. Enforce a USB device whitelist (Group Policy or a third-party tool) — block unknown USB devices by default rather than trusting anything plugged in.
2. Apply restrictive Group Policy: no access to the C: drive directly, no ability to install new programs, no unnecessary system changes — reduces what a compromised EA or indicator could actually do even if it tried.
3. Keep endpoint AV mandatory and active — treat AV being disabled or out of date as an automatic "something is wrong" signal, not a background nicety.
4. Enable Windows Event Logging for USB connections and blocked actions, forwarded to Wazuh (Section 07 → Group C → Security & identity) alongside everything else.

• USB whitelist enforced
• Group Policy restrictions applied (no C: drive access, no arbitrary installs)
• AV active, logging forwarded to Wazuh

1. Confirm this VM is included in the NUT-triggered graceful shutdown sequence (Section 04), and check whether your specific EA has a documented safe-disconnect or pause behaviour.
2. Add an Uptime Kuma monitor on this VM specifically, notification target set to ntfy (Section 07 → Group B → Monitoring & DNS, Step 7) with a dedicated high-priority topic — given real money is at stake, you want to know within minutes, not hours, and ntfy's priority flag can make that alert impossible to miss.
3. Set a PBS backup schedule for this VM, and always take a manual snapshot before changing any EA or indicator.

• VM included in graceful shutdown sequence
• Fast-notification Uptime Kuma monitor configured
• PBS backup schedule set, manual pre-change snapshot habit established

Apache Guacamole gives you RDP/VNC access to the MT5 VM through a plain browser tab (still tunneled through NetBird) — no native RDP client needed on whatever device you're checking from.

• Guacamole deployed (optional), RDP session to the MT5 VM tested through it

1. Deploy Authentik (server + worker + its own dedicated Postgres + Redis — keep this separate from the shared Database VLAN 80 instance to avoid extra firewall exceptions) on VLAN 10.
2. Complete the setup wizard, create your admin account with a strong unique password from Vaultwarden, enable MFA (TOTP or a hardware key such as a YubiKey) immediately, then disable or delete the wizard's default admin account if one remains.
3. Create an admins group (just you, for now) and a separate lower-privilege group as a template for any future limited access — never grant a new user or service account admin-group membership by default.

• Authentik deployed, own admin account created with MFA enabled
• Default/wizard admin account disabled or removed
• admins group created, scoped to just you

1. Configure Authentik's "Proxy Provider" (forward-auth mode) for each service you want gated.
2. In NPM, add the forward-auth snippet to each proxy host's advanced config (or the equivalent Traefik forward-auth middleware for anything running in the Talos cluster).
3. Start with low-risk services (Homarr, Grafana) before gating anything you rely on daily, in case the config needs tuning.

• At least one proxied service confirmed redirecting to Authentik login when unauthenticated
• Same service confirmed accessible once logged in

1. Deploy the Wazuh manager + indexer + dashboard on VLAN 50 (Monitor).
2. Install the Wazuh agent on Proxmox and any Docker/Talos hosts that support it.
3. Forward OPNsense's syslog output to the Wazuh manager.
4. Forward Authentik's authentication events to Wazuh as well, so every login — successful or failed — lands in the same place as everything else.

• Wazuh manager/indexer/dashboard deployed on VLAN 50
• Agents installed on Proxmox and at least one other host
• OPNsense syslog and Authentik events both flowing into Wazuh

1. Install the os-suricata plugin from OPNsense's plugin manager.
2. Enable it on the WAN interface first, subscribe to a free ruleset (Emerging Threats Open is the standard starting point).
3. Run in IDS mode (alert-only, doesn't block anything) for at least a week to see what fires and tune out false positives.
4. Only switch specific rule categories to IPS (blocking) mode once you've confirmed they're not flagging legitimate traffic.
5. Forward Suricata's alerts to Wazuh (Step 3) for a single combined view.

• Suricata enabled on WAN, ET Open ruleset subscribed
• Run in IDS-only mode for at least a week before enabling any IPS blocking
• Alerts forwarded to Wazuh

1. Install the CrowdSec OPNsense plugin, enrol it against the free community blocklist.
2. Point it at OPNsense's own logs plus Suricata's alerts as scenarios to watch.
3. Start in alert/log mode before enabling active blocking, same caution as Suricata's IPS step.

• CrowdSec deployed, community blocklist enrolled
• Confirmed logging real detections before switching to active blocking

Schedule a daily scan on Proxmox and/or the NAS shares, notify on detection via email or a Wazuh forward.

• ClamAV scheduled scan configured on at least one host (optional)

1. Deploy OpenVAS/Greenbone via Docker on VLAN 90 only when actively scanning.
2. Run a full scan against your own VLANs from inside the lab — this is what Phase 1 of Section 14's Security Audit uses.
3. Add Trivy as a pre-deploy check in the Argo CD/GitOps pipeline (Section 07 → Group C → GitOps foundation) to scan container images for known vulnerabilities before they ship.

• OpenVAS run at least once, results reviewed, container torn down afterward
• Trivy wired into the GitOps pipeline as an optional pre-deploy check

1. Deploy Zeek on VLAN 50, with a network tap or mirrored port on the switch feeding it traffic to observe.
2. Forward Zeek's logs to Wazuh, alongside Suricata's alerts and every other log source already centralised there.

• Zeek deployed, receiving mirrored traffic (optional — resource cost should be weighed against the budget in Section 09)
• Logs forwarded to Wazuh

1. Run Atomic Red Team tests only against the Testing VLAN sandbox (VLAN 90), never against production services.
2. Select a small number of tests relevant to the actual attack surface here — credential access, a simulated brute-force pattern against SSH, an unusual outbound connection — rather than the full library.
3. For each test run, confirm the expected alert appeared in Wazuh and the expected notification arrived via ntfy. A test that produces no alert is a genuine finding — a detection gap to fix, not a step to skip past.

• At least one test run against the Testing VLAN, confirmed to produce a Wazuh alert
• Confirmed the alert produced a notification via ntfy, not just a log entry