04 — Network, remote access, and backup power

TL;DR: Keep a way to manage your servers when the internet or normal network fails. Set up private remote access, dependable local names, and enough battery backup to shut down cleanly. Test each of those with the equipment you actually use.

Start with the network you have#

Your router, Wi-Fi system, and a wired connection for your admin computer and servers may be all you need. Before buying switches or replacing the router, ask your AI operator to check whether that equipment can support the services you have planned.

Walk through the house's connections once. Find the modem or fiber terminal, router, main Wi-Fi unit, switches, and the cables leading to each server. Label anything you would struggle to identify during an outage. If another person needs to restore internet access, put the essential instructions somewhere they can reach without using the homelab.

Ask your AI operator to prepare a diagram and equipment record for your private GitHub repository. Include the router's address, the server addresses, which device assigns addresses, which answers name lookups, and where each device gets power. Save a router configuration export separately if it contains passwords; commit a summary and the location of that export.

Prompt to paste:

Document my existing network before proposing changes. Identify DHCP, DNS,
subnets, management addresses, IPv4/IPv6 connectivity, internet-facing ports,
VPN routes, and which physical devices each connection depends on. Ask me
for a single grouped set of router screenshots or cable checks you cannot do.
Keep credentials and DNS query history out of Git and provider requests.
Save a sanitized diagram, equipment record, and recovery instructions in our
private GitHub repository. Explain which existing capabilities meet our needs
and identify any specific gap before suggesting purchases.

Keep local access independent of the internet#

Try logging in locally while the internet connection is unavailable. Use the server's numeric address if name lookup is down. Your own account must still work without a cloud login service, a working file share, or the AI operator.

Keep the direct Ethernet connection from Server setup ready for a router or switch failure. A cable sitting in a drawer is only useful if the addresses, adapter settings, and login have already been tested. Keep that information in an offline copy of your recovery instructions.

For normal use, reserve server addresses in the router. An address reservation tells the router to give a particular device the same address each time. It is easier to maintain than independently choosing fixed addresses on every computer and accidentally assigning one twice. Ask your AI operator to check for duplicates before making changes.

Connect from away from home#

This guide uses Tailscale for private remote access. Install it on your admin computer, each server that supports it, and the phone or laptop you will use away from home. It can connect devices through many home internet arrangements without exposing SSH or administration pages directly to the public internet.

Tailscale depends on an external coordination service. Keep your local recovery methods working even if that service or your internet connection is unavailable. Some connections travel through an encrypted relay rather than directly between devices; test real transfers before assuming remote access will match your home network's speed.

Protect the account you use to manage Tailscale with a passkey or multifactor authentication. Store its recovery information in your password manager and your protected offline recovery copy. Review enrolled devices and remove any you no longer recognize or use.

Decide who can reach what#

Ask your AI operator to prepare an access plan before enabling broad remote access. Your phone may need access to a media service; your maintenance laptop may need SSH and administration pages. Give each only the connections it needs.

Tailscale's policy controls connections through Tailscale. It does not automatically restrict ordinary traffic inside your house, and one device identity does not distinguish your own account from your AI operator's account on the same admin computer. Use separate server accounts, application permissions, and host firewalls for those boundaries.

If a device cannot run Tailscale, another trusted machine can act as a subnet router, forwarding permitted connections to it. Limit that access to the intended devices and ports. Avoid making your admin computer the only route to all the other machines: you need another way in when it is the computer that needs fixing.

Prompt to paste:

Prepare Tailscale access for my actual devices and users. Check the effective
policy rather than assuming enrollment restricts access. Propose default-deny
grants for the destinations and ports we need, with allowed and denied
test cases. Explain ordinary LAN paths that bypass those grants.

Keep a second working session and local recovery available during changes.
For unattended servers, explain device-key expiry, any tags, and the tradeoff
if expiry is disabled. Keep human login recovery independent of the homelab.
Test device revocation separately from enrollment-key revocation: revoking an
enrollment key does not remove devices already enrolled with it. Save the
policy and test results without credentials, then commit and push the records.

Test from cellular data#

Turn off Wi-Fi on your phone and make a new connection. Test the application or login you expect to use, then one that should be denied. Repeat from your travel laptop if you use one.

Temporarily disconnect the admin computer from Tailscale and confirm you can still reach the server independently. If you configured a subnet router, test a permitted LAN-only device through it. Finally, revoke a disposable test device and confirm that it cannot reconnect.

Check device expiry before traveling. A connection tested months ago may need a fresh login just when nobody is home to help.

If you prefer to manage the VPN yourself, WireGuard is an alternative. Ask your AI operator to compare what you would need to operate: a reachable endpoint, changing public addresses, keys, routing, firewall configuration, and recovery. Make that choice based on the maintenance you want to take on.

Restrict access inside the house too#

Ask your AI operator to inspect each server's firewall. Management connections should come only from your intended admin devices or recovery connection. Verify a permitted connection and a rejected one from actual client devices; a plausible-looking rule is not enough.

Review router features that allow applications to open incoming ports automatically, including UPnP, NAT-PMP, and PCP. If you disable them, test games, calling, and other household applications afterward so you can resolve any affected use deliberately.

A guest Wi-Fi label does not tell you everything about isolation. Test whether a guest device can initiate connections to your servers and whether the controllers you use can still reach their devices. Smart-home discovery sometimes needs multicast traffic that a separated network blocks.

Consider VLANs only when you have a concrete need to separate devices and the router, switches, and access points all support the arrangement. Have your AI operator explain the specific unwanted connection a proposed change will prevent and the legitimate connections it must preserve.

Give services dependable local names#

An address such as files.home.arpa is easier to remember than a numeric address. home.arpa is reserved for home networks; avoid using .local for ordinary DNS records because it is also used by automatic device discovery.

Use names for roles you expect to keep. For example, admin.home.arpa can identify your admin computer, node1.home.arpa a particular server, and files.home.arpa the file service. A service name can move to another machine later without changing every bookmark.

This guide uses Pi-hole to answer local name lookups and optionally block unwanted domains. Keep its records in your private GitHub repository, then have your AI operator apply and test changes through Pi-hole's supported configuration methods. Git holds the reviewed configuration and history; it does not update the running resolver by itself.

Usually the router should continue assigning addresses. Configure it to tell clients to use Pi-hole for DNS. If the router cannot do that, moving DHCP to Pi-hole is an option, but disable the old DHCP service before enabling the replacement and test that clients receive the new settings.

Avoid a misleading backup DNS setting#

Do not list a public DNS server as a second resolver for devices that need your private names. Clients may use either listed server; they do not necessarily wait for the first one to fail. The public server cannot answer your home.arpa records.

If you need a second DNS server, run another private resolver with the same records on a different machine. Keep both updated and test each directly. Check both IPv4 and IPv6 settings, since a device may receive DNS settings through either.

For remote use, configure Tailscale to send only your private domain's queries to the home resolver. This is called split DNS. Public names can continue using the client's normal resolver. Test it from cellular data, including what happens when the home resolver is unavailable.

Prompt to paste:

Set up private service names under home.arpa using our chosen resolver.
Inspect router DHCP and IPv4/IPv6 DNS advertisements first. Keep one DHCP
server per subnet. Do not use public DNS as a fallback for private names.
Validate records for duplicates and loops, save the previous configuration,
and use the installed resolver's supported API or configuration interface.

Test fresh client leases, direct queries to each resolver, local applications,
and split DNS over Tailscale from outside the house. Verify DNS is not exposed
as an unrestricted public resolver. Explain a recovery procedure using numeric
addresses when DNS is unavailable. Commit and push the records and results.

Use HTTPS where people enter accounts or private information#

HTTPS encrypts a browser connection and lets the browser check that it reached the named service. It does not decide which person may use the application; the application still needs appropriate accounts and permissions.

A publicly trusted certificate requires a domain you control. You can use such a certificate for a private service without making that service publicly accessible when your certificate setup supports verification through DNS. Be aware that public certificate records can reveal the names you request.

A private certificate authority can issue certificates for private names, but you must install its trust certificate on the devices that need to use them. Ask your AI operator to compare those options against your actual browsers, phones, TVs, and applications before building a private certificate service.

If you choose a private authority, protect its root signing key offline and back it up encrypted. Use a separately scoped issuer for routine certificates, automate renewal, and test recovery. If public certificate renewal uses a DNS API token, limit the token's access and store it as a protected service credential, outside Git and chat. Set an expiry alert either way.

Choose a place for the equipment#

Measure the space, including cable bends and room for air to circulate. Check weight, fan noise, and whether you can reach drives and ports without dismantling the setup. A tower on a ventilated shelf can be easier to live with than a rack server designed for a noisy equipment room.

If the case cannot hold your planned drives, reconsider the case or server layout before buying an external enclosure. Do not improvise an external disk box with loose SATA and power cables. The storage chapter covers suitable drive connections and expansion options.

Size battery backup for the whole connection#

A UPS supplies temporary battery power so equipment can keep running briefly and shut down cleanly. Include the modem or fiber terminal, router, necessary Wi-Fi unit or switch, DNS device, admin computer, and servers when you work out what needs power. A server that remains on is little help remotely if its router has already stopped.

Measure the load under normal use and heavier work. Have your AI operator compare that load with the UPS's watt and VA limits and the manufacturer's runtime information. Allow time for the servers to stop applications and finish shutting down as the battery ages. Recheck the measurements after adding disks or demanding applications.

One UPS can be enough initially. You can shut down the larger servers early to leave more time for networking. Separate network and compute UPS units may be useful if you need longer internet availability or different shutdown connections. A Wi-Fi unit elsewhere in the house also needs backup power if your recovery connection depends on it.

Arrange shutdown before the battery is empty#

The UPS must be able to tell a computer when power has failed and how much battery remains. Linux systems can use Network UPS Tools, or NUT, with supported hardware. One stable device reads the UPS status and tells the other machines when to shut down. Use the system's normal shutdown services; your AI operator can inspect status without holding general power-control credentials.

For the Mac mini, check whether macOS supports the UPS's USB connection directly. If a network shutdown client is required, verify that it works on the installed macOS release before depending on it. Choose equipment and a supported arrangement that you can recover without maintaining a fragile custom script.

Stop work that writes data before shutting down its storage server. Keep the network and shutdown controller available until the machines depending on them have stopped. Ask your AI operator to document the order for your particular combined or separate servers.

On power return, applications must wait until their required storage and network services actually work. Turning machines on in a particular order is not proof that they are ready. Test what happens if power returns briefly and fails again.

Prompt to paste:

Prepare UPS monitoring and shutdown for the actual UPS models, OS versions,
measured loads, and service dependencies. Use supported native shutdown paths.
Explain the battery threshold, measured shutdown time, safety margin, shutdown
order, and power-return behavior. Keep required networking and the UPS primary
available until their dependents have stopped. Give the AI operator status
access only; keep shutdown credentials in protected system services.

First test notifications and simulated actions. Then prepare one attended
power-loss test with applications idle and backups checked. Record elapsed
times and battery status, verify orderly shutdown and restart, and repeat
load measurements after the full disk and application configuration is installed.

Understand what a power strip can do#

A basic PDU distributes power to several outlets. Metered models report consumption; switched models can turn individual outlets on and off. None of those labels promises automatic recovery or a safe server shutdown.

Follow the UPS manufacturer's connection requirements and ratings. Label the plugs so you know what each outlet powers. Remote switching is optional. If you add it, test the labels physically and keep control separate from your AI operator's normal account.

Try a normal restart or use PiKVM to see the server's screen and operate its keyboard before cutting its power. Include the admin computer and every server in the PiKVM plan. For more than two computers, use a single PiKVM with a compatible KVM switch; with two, either that arrangement or separate PiKVMs works. Put PiKVM, the switch, and their network equipment on backup power, and reach the console through your private VPN. Never turn off the router you need to turn it back on unless you have already tested an automatic local power-return mechanism that works without the network.

Know whether the house is reachable#

Set up an external heartbeat check if you want notice when the whole site goes offline. A device at home can send a periodic signal out; the monitor warns you if it stops. You do not need to expose private administration pages for that check.

Start with a few actionable alerts: the site stopped checking in, storage is unhealthy, a backup is overdue, or battery shutdown needs attention. Ask your AI operator to explain what you should do for each alert and group related failures so a lost internet connection does not produce dozens of separate warnings.

Test the recovery instructions#

While someone is home and services can be interrupted, test one failure at a time. Verify local access without the internet, the direct cable without the normal switch, and remote server access while the admin computer is unavailable. Carry out the attended UPS test and confirm applications come back only when their dependencies are ready.

Write down the steps you actually needed, including cable moves and numeric addresses. Have your AI operator commit and push the updated configuration, equipment record, decisions, and results to private GitHub. Refresh the offline recovery copy too. Continue to storage and accounts when these recovery paths work.