Homelab Network Readiness
Stage VLAN splits, local DNS moves, and VPN additions on a homelab with inventory, rollback, and lockout-risk review before touching router or firewall config.
Overview
homelab-network-readiness is an agent skill most often used in Operate (also Validate and Ship) that produces a staged homelab network migration plan with VLAN, DNS, and VPN risks, validation, and rollback before config
Install
npx skills add https://github.com/affaan-m/everything-claude-code --skill homelab-network-readinessWhat is this skill?
- Read-only first pass: inventory, risks, staged plan, validation evidence, and rollback before any config paste
- Covers trusted/IoT/guest/server/management VLANs, Pi-hole/AdGuard/Unbound DNS moves, and WireGuard/Tailscale/OpenVPN acc
- Hard safety: no public exposure of admin panels, DNS, SSH, NAS, or VPN UIs; no CLI without confirmed platform and consol
- Turns informal network ideas into staged migrations with validation checkpoints
Adoption & trust: 1.2k installs on skills.sh; 210k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You want VLANs, filtered DNS, or VPN access on a home lab but fear locking yourself out of the router, switch, AP, or resolver mid-change.
Who is it for?
Operators remodeling flat LANs into segmented VLANs or adding local DNS and VPN without losing console or out-of-band access.
Skip if: Copy-paste firewall tutorials when platform and rollback are unknown, or enterprise SD-WAN designs outside home/small-lab scope.
When should I use this skill?
Before changing homelab VLANs, local DNS resolver, firewall, DHCP, or VPN—especially when lockout risk or platform is unclear.
What do I get? / Deliverables
You get a read-only inventory, risk-ranked staged plan, validation steps, and rollback path—and only then platform-specific changes when context is confirmed.
- Network inventory and lockout-risk summary
- Staged migration plan with validation checks and rollback steps
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Homelab network changes are production-adjacent operations; the canonical shelf is Operate/infra where segmentation, DNS, and VPN stability matter daily. The checklist targets gateway, VLAN, DHCP, Pi-hole-style DNS, and WireGuard-class remote access—core infrastructure readiness, not app feature work.
Where it fits
Scope whether splitting IoT onto its own VLAN is worth the DHCP and mDNS breakage before buying another AP.
Audit whether exposing a NAS or VPN management UI would violate the skill’s no-public-admin rule before launch.
Plan a maintenance-window cutover from ISP DNS to Pi-hole with validation pings and a rollback DHCP option.
Define what to watch after VLAN changes so guest Wi-Fi cannot reach management subnets.
How it compares
Readiness checklist and staged migration review—not a one-shot Ansible play or ISP support script.
Common Questions / FAQ
Who is homelab-network-readiness for?
Solo builders and homelab operators who manage their own router, DNS, and VPN and need a safety-first plan before changing network layout.
When should I use homelab-network-readiness?
Use it in Operate before VLAN or DNS cutovers; in Validate when turning a vague network idea into a phased plan; and in Ship when reviewing exposure before exposing services or VPN paths.
Is homelab-network-readiness safe to install?
The skill defaults to read-only planning and warns against public admin exposure; review the Security Audits panel on this page before letting an agent run shell or network commands.
SKILL.md
READMESKILL.md - Homelab Network Readiness
# Homelab Network Readiness Use this skill before changing a home or small-lab network that mixes VLANs, Pi-hole or another local DNS resolver, firewall rules, and remote VPN access. This is a planning and review skill. Do not turn it into copy-paste router, firewall, or VPN configuration unless the target platform, current topology, rollback path, console access, and maintenance window are all known. ## When to Use - Preparing to split a flat network into trusted, IoT, guest, server, or management VLANs. - Moving DHCP clients to Pi-hole, AdGuard Home, Unbound, or another local DNS resolver. - Adding WireGuard, Tailscale, ZeroTier, OpenVPN, or router-native VPN access. - Reviewing whether a homelab change can lock the operator out of the gateway, switch, access point, DNS server, or VPN server. - Turning an informal home-network idea into a staged migration plan with validation evidence. ## Safety Rules - Keep the first answer read-only: inventory, risks, staged plan, validation, and rollback. - Do not expose gateway admin panels, DNS resolvers, SSH, NAS consoles, or VPN management UIs directly to the public internet. - Do not provide firewall, NAT, VLAN, DHCP, or VPN commands without a confirmed platform and a rollback procedure. - Require out-of-band or same-room console access before changing management VLANs, trunk ports, firewall default policies, or DHCP/DNS settings. - Keep a working path back to the internet before pointing the whole network at a new DNS resolver or VPN route. - Treat IoT, guest, camera, and lab-server networks as different trust zones until the operator explicitly chooses otherwise. ## Required Inventory Collect this before giving implementation steps: | Area | Questions | | --- | --- | | Internet edge | What is the modem or ONT? Is the ISP router bridged or still routing? | | Gateway | What routes, firewalls, handles DHCP, and terminates VPNs? | | Switching | Which switch ports are uplinks, access ports, trunks, or unmanaged? | | Wi-Fi | Which SSIDs map to which networks, and are APs wired or mesh? | | Addressing | What subnets exist today, and which ranges conflict with VPN sites? | | DNS/DHCP | Which service currently hands out leases and resolver addresses? | | Management | How will the operator reach the gateway, switch, and AP after changes? | | Recovery | What can be reverted locally if DNS, DHCP, VLANs, or VPN routes break? | ## VLAN And Trust-Zone Plan Start with intent rather than vendor syntax. | Zone | Typical contents | Default policy | | --- | --- | --- | | Trusted | Laptops, phones, admin workstations | Can reach shared services and management only when needed | | Servers | NAS, Home Assistant, lab hosts, DNS resolver | Accepts narrow inbound flows from trusted clients | | IoT | TVs, smart plugs, cameras, speakers | Internet access plus explicit exceptions only | | Guest | Visitor devices | Internet-only, no LAN reachability | | Management | Gateway, switches, APs, controllers | Reachable only from trusted admin devices | | VPN | Remote clients | Same or narrower access than trusted clients | Before recommending VLAN IDs or subnets, confirm: 1. The gateway supports inter-VLAN routing and firewall rules. 2. The switch supports the required tagged and untagged port behavior. 3. The APs can map SSIDs to VLANs. 4. The operator knows which port they are connected through during the change. 5. The management network remains reachable after trunk and SSID changes. ## DNS Filtering Readiness Pi-hole or another local resolver should be introduced as a dependency, not as a single point of failure. 1. Give the resolver a reserved address before using it in DHCP options. 2. Confirm it can resolve public DNS and local `home.arp