In my last post about The Construct, I mentioned building a Claude Code skill to onboard new services into the deployment pipeline. That worked well enough that I kept pulling on the thread: if an AI agent can be trusted to write deployment configs, what else can it be trusted to run day-to-day? The answer I landed on was a small storefront operation I run out of the same homelab (mostly 3D-printed and laser-cut products), and that raised a question the deployment skill never had to answer, because Ansible playbooks don't need write access to real, ongoing storefront data.

The question was: how much access does an agent actually need, and how do you make sure it never gets more than that, while still keeping the data it does need right at its fingertips, not buried behind a request I have to broker by hand every time?

The Setup: Several Storefronts, One Assistant

I run a handful of small storefronts side by side: different product lines (3D-printed goods, laser-cut goods, a couple of others), different workflows, different data. Each one now has a dedicated Cowork skill: read a cost ledger, draft a listing, close out an issue, tell me what's pending. That's genuinely useful, right up until you think about what it implies. An assistant that can write to live, ongoing storefront data needs somewhere to write to, and "somewhere" is exactly the kind of vague scope that turns into a real problem the first time a skill misfires.

I'd already gone through this exercise once, with the Zone-Based Firewall from a couple posts back: don't give broad trust when a narrow boundary does the same job. Same principle, one layer up the stack. This time the thing needing a boundary wasn't a Zigbee bulb, it was an agent with write access to a git repo.

Repurposing a Repo: Not for Code, for Context

Worth naming the obvious oddity here: a git repo is built for source code, not cost ledgers and listing copy. That's a non-traditional use of the tool, and I went with it anyway, because the properties that make a repo good for code turn out to matter just as much for storefront data: versioned history, plain-text files that diff cleanly, a folder structure that means something on its own.

The part that sold me wasn't the versioning. It's that the same file works twice. A markdown file sitting in a repo is presentable to me (I can open the folder and read it like a document), and it's just as legible to the agent reading it back for context. One data store, two audiences, no translation layer in between.

That second audience is the real shift. One of my skills even standardizes its draft files on a plain README.md instead of a custom filename, purely because it renders natively the moment the folder is opened, presentable to a human glancing at the repo, and parsed the same way by the agent working inside it. A repo stopped being just where code lives and became the shared surface where I hand data to my agent team and get it back in a form I can actually read.

Why Cowork, Not Code

I could have wired this up as a Claude Code integration instead. It's closer to how The Construct's onboarding skill runs. I deliberately didn't. Cowork's whole shape is built around a single local MCP connection per session; there's no path for it to reach past that connection unless I go build one myself. Claude Code assumes a broader kind of trust by design: it expects to operate across a whole codebase with shell access, and I'd have had to manually claw all of that back down to get the same guarantee Cowork gives me for free.

Choosing Cowork wasn't about which tool was more convenient. It was picking the tool whose default shape already matched the boundary I wanted, instead of building a boundary on top of a tool that assumes it doesn't need one.

The Hard Boundary: One Org, Nothing Else

The lazy version of this is pointing an agent at "my Gitea" and calling it done. I didn't do that. There's a local MCP server dedicated to this entire arrangement, and it authenticates as a dedicated Git account whose own permissions are limited to exactly one org and that org's repos: not my account, not my other projects, one org.

The distinction matters. Cowork can read and write inside that org's repos all day. It has no path to anything outside it: no other orgs, no other repos, no way for a misfiring skill to reach past the fence, because there's nothing on the other side of the fence for it to reach, and no account credential that would let it try.

This is the same shape as the Guest Zone from the firewall post: access to exactly what's inside the boundary, enforced twice over, by the MCP server's own scope and by the account it authenticates as, not by good behavior.

The Soft Boundary: One Repo Per Storefront

Inside the org, the repos split by storefront, and each skill is written to operate on its own repo only. A couple of the storefronts do legitimately overlap (shared source designs, overlapping audiences between the 3D-printed and laser-cut lines), and the skills know about that overlap and flag it when relevant. They just don't act across the boundary to resolve it themselves.

Worth being precise about what kind of boundary that is. The org scope is enforced twice: once by the MCP server's own configuration, and again by the Git account the MCP server authenticates as, whose permissions are limited to that org and its repos regardless of what the MCP config says. Neither layer has a setting that lets a skill see outside it. The repo-per-storefront split is a different kind of thing entirely: it's enforced by how the skills are written, a convention, not a permission either layer checks. It's the difference between a locked door and an agreement not to open one. Both matter. Only one of them is unbreakable.

Solving the Binary Problem: Git LFS

Scoping access solved half the problem. The other half was that a git repo without LFS falls over the moment you commit real production files, and 3D and laser production files are not small: print files for one, cut files for the other.

LFS is enabled at the org level, with storage redirected server-side to a separate, larger pool built for it. Each repo's .gitattributes tracks the binary types it actually has reason to hold:

*.stl filter=lfs diff=lfs merge=lfs -text
*.3mf filter=lfs diff=lfs merge=lfs -text
*.svg filter=lfs diff=lfs merge=lfs -text
*.jpg filter=lfs diff=lfs merge=lfs -text
*.png filter=lfs diff=lfs merge=lfs -text

Not every repo needs the same rules: the 3D-printed line tracks .stl/.3mf, the laser line tracks its own cut-file formats, and one of my repos is text and copy only with no binary asset to track at all. That's not an oversight. Enable LFS where the problem exists, skip it where it doesn't.

What this actually bought me is the thing I was missing before: a product's real print or cut files now live in the same folder as the listing copy describing them, under the same commit history, instead of two systems that only stayed in sync because I remembered to update both by hand. That's a genuine long-term storage solution for production files, with the diffable, text-based organization a git repo gives you for free.

Where the Agent Still Isn't Trusted

None of this means Cowork writes the binaries itself. The MCP's file-write call takes a plain string. Push raw binary bytes through a string parameter and you risk silent corruption. And a corrupted production file is a worse outcome than no file at all.

So the skills are explicit about the limit: draft the text, reference real filenames once I've given them, and leave the actual binary commit to me, by hand, the way I'd do it anyway. It's a deliberate seam, not a gap nobody's gotten to yet.

Giving an agent full context on a storefront's assets (real filenames, real folder structure, what's committed versus what's still a placeholder) doesn't require giving it a write path into a format it can silently break. It gets to know everything. It doesn't get to touch the one part of the pipeline where a mistake is expensive.

The Whole Picture

Everything in Phase 1 is where the agent actually lives: one connection, one gate, no path outward if the answer is no. Phase 2 is the explicit read/write line running to every storefront repo, none skipped, none reached by any other route. Phase 3 is the split that matters most: text goes straight from the agent into the repo, binaries get routed to LFS and committed by hand, and one storefront never even enters that second path because it has no binaries to begin with.

The Result

Several storefronts, one scoped org, LFS handling the 3D and laser production files a plain git repo was never going to manage gracefully, and an assistant that can act across all of it without holding a key to anything else. The hard boundary is the org scope: that one's enforced whether the skills behave or not. The soft boundaries (repo-per-storefront, text-only writes) are discipline, documented in the skills themselves, doing the same job a stricter permission model would, without needing one.

Same lesson as the firewall, just applied to an agent instead of a network: figure out the smallest boundary that still gets the job done, then build it so nothing has to remember to respect it.

There's a better way. Treat every service in your home lab the same: same deployment process, same security model, same observability. Not because it's merely elegant, but because consistency is what makes a home lab maintainable.

This post walks through how I built that system, and more importantly, why you should too.

What Is Infrastructure as Code?

Before getting into the specifics, it's worth establishing what infrastructure as code actually means in practice, because the term gets thrown around loosely.

The idea is simple: every configuration decision that describes your infrastructure is captured in a file, committed to version control, and applied by a machine rather than typed by hand. Instead of SSH-ing into a server and running commands, you write a playbook that describes the desired state, and a tool like Ansible makes it so.

This isn't just about automation. The deeper value is that your infrastructure becomes auditable, reproducible, and moveable. Anyone looking at your repository can understand exactly what a server does and why. Rebuilding a failed node is re-running a playbook, not piecing together notes from memory. Migrating a service to new hardware is changing one variable.

Done right, you should never have a server you're afraid to wipe.

Stop Writing Deployment Scripts Per Service

Here's the trap most people fall into: they write deployment logic inside each service's repository. Service A has its own deploy.sh. Service B has a different one. Service C has a GitHub Action. After a while, you have six services and six different deployment models. You fix a security bug in one and forget to apply it to the others.

The solution is a single, centralized pipeline repository that contains all the deployment logic for your entire cluster. Every service points at it. Every service benefits when it improves.

I call mine The Construct. It's a single Ansible roles library. When I bring a new service into the cluster, I don't write new deployment logic. I write a short configuration file that hands off to the same roles every other service uses.

When I fixed the secret handling to use RAM instead of disk, every service in the cluster got that fix on its next deploy. When I added automatic health checks, every service got health checks. One improvement, total coverage.

That's the leverage you get from centralizing.

The Architecture: Core & Satellite

The Construct follows a Core & Satellite model. The central Construct repository holds all the shared Ansible roles. Individual Code repos each contain a single deploy.yml that imports those roles and supplies service-specific configuration: the hostname, the project path, the secrets, the health check endpoints.

The Construct (shared roles, one place, one version)
└── roles/
├── docker-deploy      ← handles every Docker service
├── lxc-provision      ← provisions the host itself
├── nfs-mount          ← mounts storage
├── service-validation ← health checks
├── mqtt-notify        ← telemetry
├── recordDeploymentMetadata ← audit trail
└── image-prune        ← cleanup

The Code (e.g., Caliper)
└── deploy.yml               ← ~50 lines of config, no logic

The Architect is the orchestrator, self-hosted and local with no cloud CI. When a deploy triggers, The Architect clones both The Construct and the Code repo into a workspace and hands control to Ansible. It also supplies the vault secrets (API keys, database passwords) that services need at runtime.

The execution targets live in The Galaxy: Alpine or Ubuntu LXC containers running on PVE nodes, each dedicated to a single service and named after a Star Wars planet. Ansible reaches them over SSH through the bastion host via ProxyJump. Nothing in the cluster is directly reachable from the management plane.

Built to Move

The other discipline worth enforcing from day one: nothing in your infrastructure should be hard to rebuild or migrate.

This is where IaC pays off beyond just automation:

• Hosts are code. Every node in The Galaxy is provisioned by the lxc-provision role. Its VMID, hostname, IP, OS template, and NFS configuration live in a playbook. Reprovisioning a failed node is one Ansible run.

• The server holds a container. The repo holds the truth. Service configuration lives in Git, not in the server's filesystem. If the server disappears, the configuration doesn't.

• Secrets are portable. They live in The Architect's variable groups, not on disk, not in the repo. Moving to a new Architect instance means exporting the vault. Nothing is trapped.

• Every deploy is idempotent. Running the same playbook twice with no changes produces no changes. Re-deploying is always safe, which means rollbacks and re-runs are never scary.

If a PVE node failed today, I could rebuild every service it hosted by running playbooks against a new node. No tribal knowledge required. No reconstructing configuration from memory. The code is the documentation.

Aim for that. If you have a server you'd be afraid to wipe and rebuild, that's a problem to fix.

The Eight-Phase Deployment

Every service in the cluster runs through the same eight-phase sequence. Having a standard flow means there are no surprises when something goes wrong. You know exactly where in the pipeline a failure occurred.

1. Notify: MQTT status published as "Updating". Home Assistant sees this immediately.

2. NFS Validation: If the service uses network storage, the Black-Hole Check runs before anything else proceeds.

3. Alpine Dependencies: For Alpine nodes, rsync and nfs-utils are installed dynamically if needed.

4. Sync: The Code repo is rsynced to /opt/<service>/ on the node, excluding anything in .deployignore.

5. Secret Injection & Docker Up: The atomic block: write to RAM, launch the stack, wipe from RAM.

6. Health Checks: HTTP responses, DNS resolution, and database readiness (Postgres, MySQL, Redis) are probed against configured endpoints.

7. Audit Log: The Git SHA, deployer identity, branch, and a UTC timestamp are written to /etc/wizard/deployments/ on the node.

8. Image Prune & Final Notify: Dangling Docker layers are removed, and a success event publishes to MQTT.

Every phase runs inside block/rescue. If anything breaks, MQTT publishes a failure event before the error propagates. The broker always reflects current state.

Deep Dive: Phase 5 & The Secret Handling Problem

Here's a specific problem worth solving deliberately: where do your secrets go during a deploy?

The obvious answer is a .env file. Copy it to the server, docker compose picks it up. It works. It's also a quiet security failure. That file sits on disk indefinitely, shows up in backups, and travels wherever your rsync does. Most home labs have a graveyard of .env files in /opt/ that nobody remembers putting there.

The better answer: secrets should never touch disk at all.

The Construct implements a RAM-only secrets model. When a service needs secrets injected at deploy time, the docker-deploy role writes the .env content to /dev/shm (a tmpfs mount that exists only in RAM), launches the stack, then immediately deletes the file in an always block that runs whether the deploy succeeded or failed.

always:
  - name: SECURE CLEANUP - Remove .env from RAM
    ansible.builtin.file:
      path: "/dev/shm/{{ mqtt_topic }}.env"
      state: absent
    when: envContent | default('') != ''

The file never touches the physical disk of the Galaxy node. If the deploy crashes mid-run, the next run sweeps orphaned files before doing anything else. Ansible logs never capture the secret content because no_log: true suppresses the task output entirely.

If you're wondering how containers stay authenticated once that file vanishes, it's because docker compose up -d completely parses the .env file at instantiation. It injects those variables directly into the isolated process memory space of the newly spawned containers. Once the >stack is initialized, the container holds onto those keys internally, allowing the pipeline to safely shred the physical file from RAM without interrupting the active runtime environment.

This is the kind of thing that's easy to implement once and hard to remember to implement in every one-off script. A centralized pipeline means you make the right call once and it applies everywhere.

The Black-Hole NFS Check

If your services use network storage, add this check to your pipeline. When an NFS mount fails silently, Docker writes to the local root filesystem instead, and you won't notice until something fills up.

The trap with typical directory checks (like Bash’s -d /mnt/nfs) is that if a remote share drops or fails to mount, the local mount-point folder itself still technically exists on the host's root disk—it's just completely empty. A standard script sees the folder, assumes everything is fine, and lets Docker blindly dump gigabytes of data directly onto your host's root OS drive.

By using Ansible's stat module to compare the underlying storage device IDs (stat.dev), we can programmatically verify whether the mount point has successfully decoupled from the system root:

- name: Stat NFS mount point
  ansible.builtin.stat:
    path: "{{ nfsMountPath }}"
  register: mount_stat

- name: Stat system root
  ansible.builtin.stat:
    path: "/"
  register: root_stat

- name: Fail if NFS not mounted separately
  ansible.builtin.fail:
    msg: "NFS mount check failed: {{ nfsMountPath }} is on the root filesystem."
  when: mount_stat.stat.dev == root_stat.stat.dev

If dev matches root, the NFS share isn't mounted. The deployment aborts before anything runs. It's a one-time addition to your pipeline that protects every service that uses shared storage.

MQTT as the Telemetry Bus

Every deployment phase in The Construct publishes to the internal MQTT broker, the same broker handling sensor state and automation events throughout the home. If you're already running Home Assistant with an MQTT broker, this is worth wiring up.

The benefit is that deployment events flow into the same system you're already watching. Deployment state appears in dashboards alongside temperature and presence data. But it goes further than visibility.

Because the broker is a universal event bus, any service that speaks MQTT can react to deployment events. n8n (a self-hosted workflow automation tool) can subscribe to deployment topics and trigger follow-on processes automatically: running database migrations after a successful deploy, posting a notification to a channel, or kicking off integration tests. The Construct publishes the event; n8n decides what to do with it.

The other side is failure alerting. When a deployment breaks, the rescue block fires an MQTT event before re-raising the failure. That event routes to a personal push notification with the service name, the host, and the timestamp, so I know something went wrong without log diving.

/ansible/caliper      → "Updating - 05/22/2026 14:32:01"
/deployment/caliper   → "05/22/2026 14:32:44 - ✅ Deployment of caliper completed on endor"
/deployment/caliper   → "05/22/2026 14:33:12 - 🛑 Failed to deploy caliper on endor"

The same system that tells you a door was left open can tell you a deployment failed.

Testing: Every Role Has Molecule

If you build a shared pipeline library, test it. Each core Ansible role powering these deployment phases has a Molecule test suite that runs on every push via Gitea Actions.

Infrastructure code has an honest testing problem: you can't fully simulate a real deployment in CI. You can't SSH into a PVE node, mount a real NFS share, or reach the MQTT broker. Some things can only be validated against real hardware.

What Molecule catches is everything else, and that's still a lot. Idempotency violations (running the same role twice should produce no changes on the second run), incorrect conditionals, broken variable references, logic that works on Ubuntu but fails on Alpine. These are the errors that would otherwise surface mid-deployment against a live service. For a shared library that every service in the cluster depends on, catching them early is worth the test setup.

The real-hardware gaps get validated the old-fashioned way: against actual nodes before merging anything that touches those code paths.

The One Rule That Doesn't Bend

Whatever pipeline you build, establish one non-negotiable: secrets never touch persistent storage. Not /opt/. Not /etc/. Not /tmp/. RAM only.

Disk is durable and RAM isn't. A reboot clears /dev/shm. A forensic investigation of the filesystem finds nothing. A backup of /opt/caliper/ contains no credentials. This rule is easy to implement once in a centralized pipeline and impossible to enforce consistently across a dozen one-off scripts.

Onboarding with an AI Agent

The Construct is well-documented, but documentation still requires someone to read and apply it correctly. To close that gap, I built a Claude Code skill that fully understands The Construct: the role catalog, the variable schema, The Architect's configuration model, and the naming conventions.

When bringing a new service into the cluster, the workflow is now: describe what the service does, whether it needs NFS, what endpoints it exposes, and what secrets it requires. The skill generates a complete deploy.yml from those answers, correctly wired to The Construct's roles. It also walks through exactly what to configure in The Architect (which repository to register, how to structure the variable group, how to set up the template and inventory) so the first deploy runs without touching the documentation.

This works because the pipeline is consistent. Because every service is configured the same way, an agent that understands the pattern can onboard any service that follows it. The centralization that makes The Construct maintainable is the same thing that makes it teachable to an AI.

Build The Construct First

If there's one thing to take from this: create your centralized pipeline repo before you create your second service. Once deployment logic is scattered across individual repos, consolidating it is a project. Starting with a shared library means every service you add makes the whole system more valuable, not more complex.

Your pipeline should have one job: take a service from "code in a repo" to "running container on a node" in a repeatable, auditable, secure way. Everything else (observability, storage validation, health checks, audit trails) follows naturally once that foundation exists.

Build it once. Deploy everything with it.

In my last post I went deep on the firewall that keeps my network segmented and secure. Today I'm shifting to principle 03: Simplicity; using my blinds automation as the case study.

Blinds are one of those things that seem too simple to automate intelligently, and too trivial to bother building properly. That assumption is wrong on both counts. Done right, a blinds automation disappears entirely. Nobody in the house thinks about the blinds. They open when they should. They close when they should. When you come downstairs on a Saturday morning the light is already right. That's the goal.

Getting there took more iteration than I expected.

The Hardware

The blinds run on eWand Zigbee motors — one per blind, installed inside the standard wand mechanism. They pair directly into ZHA (Zigbee Home Automation) in Home Assistant and appear as switch entities. No hub, no cloud, no app.

The Zigbee integration was deliberate. These motors run locally. If the internet is down, the blinds still work. If eWand's servers go down (or the company disappears), nothing changes. I control the device; I don't rent access to it.

The one trade-off with eWand is that they expose as switches rather than proper cover entities — on or off, not a position percentage. For most blinds, that's fine. You want them open or closed, not 47% open.

Before buying any smart home hardware I check one thing: does it work locally with Home Assistant without needing the manufacturer's cloud? eWand does. That's the whole criteria.

The Architecture: One Script to Rule All Zones

Most automations I see hardcode device entity IDs directly into their logic. It works until you add a device, rename something, or reorganize a room — then you're hunting through YAML to patch five different automations.

I took a different approach. Every blind in the house carries two Home Assistant labels: Blinds and its zone — Living Room, Breakfast Room, Dining Room, Primary Bathroom, or Sun Room. The central script.blinds doesn't know which entities exist. It discovers them at runtime.

devices: >
  {%- set data = namespace(deviceList=[]) -%}
  {% set blinds = label_entities('Blinds') %}
  {% set room = label_entities(zone) %}
  {%- for x in blinds -%}
    {%- if x in room -%}
      {%- set data.deviceList = data.deviceList + [x] -%}
    {%- endif -%}
  {% endfor %}
  {{data.deviceList}}

The script takes two arguments: order (open or close) and zone. It resolves the right devices dynamically, runs the command, and retries anything that didn't respond. Adding a new blind to the living room means applying two labels in Home Assistant. The automation picks it up automatically on the next run.

That's the kind of design that survives years of hardware changes without accumulating technical debt.

The Safety Guard

Not every room should open on the same schedule. The primary bathroom has different morning timing from the living room. Some zones; such as the living room and sunroom benefit from early light regardless of the day. Others should stay closed on weekdays until people are actually moving around.

The script enforces this with a single template condition that gates all open commands. Three cases allow the script to proceed:

Close commands always execute. Privacy and heat control are non-negotiable. If the order is to close, it runs immediately, no conditions checked.

Special zones have restricted schedules. The Breakfast Room and Dining Room are flagged as specialScheduleZones. These zones are restricted to a workday check where they only open on Weekends and Holidays

Weekends and holidays are unblocked. When the Workday sensor is off, all zones open on their normal schedules. The system knows it's Saturday.

One template condition, three cases, clean logic. No per-zone automation files, no duplicate guards scattered across the system.

The Reliability Loop

Zigbee devices occasionally miss a command. It's rare, but a blind that doesn't respond means one blind closed out of three in the living room — which is worse than none at all.

The script handles this with a built-in retry loop. After sending a command, it waits ten seconds, checks whether each device is in the expected state, and re-sends to any that aren't. It keeps doing this until every device in the zone matches the target state.

repeat:
  while:
    - condition: template
      value_template: |
        {% set data = namespace(status = false) %}
        {% for device in devices %}
          {% if states(device) != order %}
            {% set data.status = true %}
          {% endif %}
        {% endfor %}
        {{data.status}}
  sequence:
    - action: switch.turn_{{order}}
      target:
        entity_id: "{{ devices }}"
    - delay:
        seconds: 10

The automation doesn't require a perfect mesh. It requires an eventually consistent one. That's a more honest target.

The Three Triggers

Three things change the state of the blinds in this house:

Sundown State Change is the primary driver. A SunDown input boolean toggles at sunrise and sunset, automatically calculated by Home Assistant based on location. At sunset, all zones close in parallel — seven simultaneous script calls, one per zone. At sunrise, the first-floor zones open. The primary bedroom is intentionally excluded from the sunrise open; that one has its own logic.

Primary Bathroom Morning Schedule runs independently. On workdays, it opens at 8 AM. On weekends and holidays, it waits until 9 AM. The workday condition is checked at the trigger level here, since the timing difference is meaningful and zone-specific.

Temperature Override is the one that bypasses everything else. When the outside temperature sensor crosses 78°F, all zones close. Immediately. No schedule check, no zone exceptions. Heat gain is a physical problem and it doesn't care what day of the week it is.

The temperature close was the automation I resisted building longest. It felt unnecessary. Then I had a week in August where the AC was running hard while the blinds were open and I couldn't figure out why the house wasn't cooling. It was not unnecessary.

Voice Control Without Confusion

eWand motors appear as switch entities in Home Assistant — which means a voice assistant would say "turn on" and "turn off" instead of "open" and "close." That's a small thing that makes voice control feel broken.

The fix is an abstraction layer. Each zone gets a Cover helper built from its switch group. The Cover entity exposes "open" and "close" semantics, hides the on/off language, and maps to the underlying physical switches. Only the cover entities are exposed to voice assistants. The physical switches stay hidden.

"Hey Google, close the living room blinds" works the way you'd expect, because the entity it's talking to is modeled as a blind, not a light switch.

The Result

The blinds in this house have been running without manual intervention for over three years. Nobody in the family thinks about them. They open in the morning, close at sunset, and close themselves when it's hot outside. Physical switches still work — walk up to any blind and twist the wand and it responds immediately, same as before automation.

That's what principle 03 actually looks like in practice. Not a clever system with fifteen configuration options. A system that handles the routine cases automatically, stays out of the way when someone wants manual control, and has exactly one interface for each use case: time, sun position, temperature, and voice.

When I evaluate whether an automation is worth keeping, I ask one question: has anyone complained about it? The blinds have never come up. That's the benchmark.

Most smart home setups fail not because of bad hardware, but because they neglect the fundamentals. After years of designing and refining my own system, I've settled on five non‑negotiable principles.

There's a common trap with home automation: you start with a few smart bulbs, then a thermostat, then some door sensors and before long you're juggling 40 devices across six apps, including three that depend on cloud services that went offline at 2 a.m. last Tuesday.

That chaos is the default state of the modern smart home. To avoid it, you have to stop thinking about gadgets and start thinking about systems.

01 · Reliability

The Foundation

A smart home that doesn't work when you need it is worse than no smart home at all. Imagine your front door lock failing on a cold night because your Wi-Fi router rebooted or a cloud server in another state went offline. That’s not a hypothetical; it’s the inevitable result of a poorly planned system.

Reliability starts with moving away from a Wi-Fi-only mindset. While Wi-Fi is great for high-bandwidth tasks, it’s a bottleneck for home automation. I’ve built a resilient environment by offloading my sensors and critical controls to dedicated mesh protocols:

Zigbee: This is my workhorse. I run two separate Zigbee networks to manage a dense mesh of contact, motion, and mmWave presence sensors, along with non-invasive vibration monitoring for my generator.

Z-Wave: I reserve this for critical controls like fan speeds to keep traffic off the 2.4GHz spectrum.

BLE: For niche devices like SwitchBot blinds, I use an ESP32 BLE proxy to bridge them without range limits.

By moving these off the Wi-Fi, my automations don't care if the internet hiccups. For truly critical systems—climate control and security—I always build in fail-safes. A good smart home doesn’t just "break"; it degrades gracefully.

02 · Security

Non-negotiable

In a Digital Homestead, you don't trust the device manufacturer to secure your home; you secure the environment around the device. My security posture is built on a Zone-Based Firewall (ZBF) running on a UniFi Dream Machine Special Edition (UDM SE), splitting my infrastructure into six isolated zones: Control, Smart, Services, User, Camera, and Guest.

To manage access to these zones, I follow three strict rules:

Reverse Proxies for Web Traffic: All 443 (HTTPS) traffic hitting my Services network is funneled through reverse proxies. This gives me a single point of entry to manage SSL and access logs without exposing individual application ports to the internet.

The Zero-Direct-SSH Rule: I have removed direct SSH access from my internal services. Instead, all administrative traffic must pass through a hardened Bastion Host. It’s a dedicated gatekeeper that enforces modern ciphers and key-only authentication.

DNS-Filtered Internet Access: While my Smart devices have internet access, they don't have free access. All traffic is routed through a DNS-based ad blocker. This allows devices to reach necessary update servers while silently dropping the aggressive telemetry and tracking requests that most IoT hardware tries to phone home with.

03 · Simplicity

Often overlooked

The best automation is the one nobody notices. If your family members are constantly fighting with automations, or asking you to "turn off the smart stuff," you've overcomplicated it.

My rule: automations should work silently in the background, triggered by presence, time, or sensor data — not by someone having to open an app. The lights in my office turn on when I sit down and off when I leave. Nobody thinks about it. That's the goal.

Just as important: every automation needs a simple physical override. Switches still work as switches in my house. So anyone can control anything without needing a phone or asking Alexa. Automation should enhance control, not replace it.

Before I add any new automation, I ask myself: does this make something easier for everyone, or just more complex? If it requires explanation, it usually doesn't get built.

04 · Interoperability

Future-proofing

The smart home industry is littered with the corpses of proprietary ecosystems. Wink. SmartThings hubs. Insteon. Each one left users stranded when the company pivoted or shut down. Betting your home's infrastructure on a closed ecosystem is a risk not worth taking.

I bias heavily toward open, device-agnostic standards: Zigbee and Z-Wave are my current pillars because they are mature, community-maintained, and run entirely locally. Home Assistant serves as my central nervous system because it integrates with almost everything and ensures I own my data.

Before buying any device, I check whether it works locally with Home Assistant without needing the manufacturer's cloud. If the answer is no, I look for an alternative. There almost always is one.

05 · Supportability

The long game

Your smart home is infrastructure. Like any infrastructure, it needs to be maintainable — by you, and ideally by someone else if you're ever unavailable. That means good documentation, logical naming conventions, and avoiding setups so clever that only you understand them.

Local control is central to this. If my internet goes down, my automations still run. If Home Assistant's servers go down (they don't have any — it's self-hosted), nothing changes. I control the entire stack.

I document everything in a private wiki: network diagrams, architectural decisions, and the logic behind every automation. But the real game-changer has been moving my documentation into a local git repo and using AI agents to help maintain it.

Avoid vendor lock-in wherever possible. Own your data. Run things locally. And when you do use cloud services, make sure there's a local fallback.

These five principles didn't come from reading a guide — they came from breaking things and rebuilding them. Every shortcut I took early on eventually cost me more time to fix than it saved.

In future posts I'll go deeper on each of these: the specific hardware I use, how my network is segmented, and the automations that actually stuck after years of iteration.