Agricultural operations with multiple sites face a specific question that single-site operations do not: how many Home Assistant installations, and how do they relate? A grower with three greenhouses a mile apart can run one Home Assistant instance that reaches all three, if the network supports it. A grower with two farms forty miles apart almost certainly runs separate instances per site, because a reliable network between them is either expensive or impossible. A seasonal operation that opens a summer satellite location has yet another pattern — one primary instance, one occasionally-connected secondary. The right architecture depends on distance, network reliability, operational independence of the sites, and the operational pattern the grower prefers. This page covers the three main architectures (single-instance-multi-location, federated instances with centralized visibility, fully-independent instances with human coordination), the networking between sites, centralized dashboarding that makes sense, cross-site alerting, user access patterns across sites, backup and update coordination, and the specific failure modes that affect multi-site deployments. The foundational reliability discipline from Phase 9 applies per-site; multi-site operations extend it with coordination layers that have their own failure modes worth understanding.
Before designing multi-site architecture.
Prerequisites and framing.
Know why you have multiple sites. Greenhouse zones that could be one operation's multiple rooms versus genuinely separate farms with independent operational decisions imply different answers. If the sites are operationally one thing (same crop plan, same staff, same oversight), the architecture leans toward centralization. If the sites are operationally independent (different crops, different staff, different ownership even), the architecture leans toward independent instances.
Understand the network reality. The single most important technical factor. A reliable low-latency local network across sites means one instance can reach all of them. Unreliable or high-latency inter-site connectivity means separate instances with whatever coordination layer makes sense. Measure before designing — latency, packet loss, uptime of the inter-site link. Assumptions about "usually good enough" routinely break under operational pressure.
Decide what must be centralized. Some operations want a single dashboard covering all sites — the owner's morning view shows every zone across every site. Other operations treat each site as its own concern, with only exceptional events reaching the central level. Know what the operation actually wants before building for it.
The single-operator versus multi-operator question. A single grower responsible for all sites has different needs than separate teams at each site. Centralized dashboards serve the single-operator case; local dashboards at each site with aggregated overview serve the multi-operator case.
Baseline reliability first. Each site's own Home Assistant needs to be reliable per the Phase 9 discipline — backups, monitoring, updates, security. Multi-site adds coordination; it does not substitute for each site being sound. Building multi-site on top of unreliable individual sites produces unreliable multi-site.
The three architectures.
Each site can run separately, or one instance can span multiple sites, or something in between.
Architecture A: Single instance, multiple locations. One Home Assistant installation covers all sites. Devices at each site connect to the central instance over the network. Works well when sites are connected by a reliable local network — same building, same campus, neighboring properties with good connectivity. Breaks down when the network between sites is unreliable; a brief network outage means the remote site's devices are unavailable until the network returns.
Architecture B: Federated instances with coordination. Each site has its own Home Assistant installation. The installations communicate — through MQTT bridging, through the Remote Home Assistant integration, through custom integration patterns, or through a shared data layer. Each site operates independently even when inter-site communication is down; coordination produces shared visibility when it works. The middle ground; often the right fit for multi-site agricultural operations.
Architecture C: Fully independent instances. Each site has its own Home Assistant, and they do not communicate at all. The grower has separate dashboards per site, accessed independently. No automatic cross-site coordination; the coordination happens through the grower's attention. Works for operations where the sites really are operationally independent — different crops, different growth patterns, different operational rhythms.
Choosing among them. The network reality drives much of the decision. Distance and inter-site connectivity determine whether A is feasible. The operation's preference for centralization versus independence determines whether C or B fits better. For operations in the middle — multiple sites close enough to communicate reliably but independent enough to warrant their own autonomy — B is the common choice.
Architecture A: Single-instance multi-location.
When one Home Assistant covers everything.
The network requirement. A reliable local network spanning all sites. Ethernet is ideal; WiFi within a single building is fine; point-to-point wireless bridges between buildings can work if the bridges are robust. Latency should be low (a few milliseconds typically); packet loss should be near zero.
Device connectivity. Devices at each site connect to the Home Assistant instance through whatever protocol is standard — MQTT for ESP devices and many others, WiFi for smart plugs, Zigbee through a coordinator. The coordinator's location matters for Zigbee and Z-Wave — their range is limited; multi-site deployments may need satellite coordinators (which Home Assistant supports for some integrations but not all).
Zone organization. Areas in Home Assistant map to sites naturally. "Greenhouse 1," "Greenhouse 2," "Propagation Building" — each becomes its own area, with its own entities, its own automations, its own dashboards.
When this works well. Multiple greenhouses on one property, a farm office and adjacent production buildings, a propagation building and attached production greenhouses. The physical connectivity is there; the operational management is unified; one Home Assistant is enough.
When this struggles. Sites separated by significant distance, sites where the inter-site network has variable reliability, sites where operational independence matters, sites where local staff need control when the central network is down. The single-instance pattern becomes fragile at the network boundaries.
Architecture B: Federated instances.
Each site runs its own Home Assistant; coordination happens through specific patterns.
MQTT bridging. Each site's MQTT broker can bridge to a central broker. Selected topics from each site's broker are published to the central broker; the central broker can be consumed by a central Home Assistant or by a dashboard aggregator. This is a durable, well-understood pattern; MQTT brokers like Mosquitto support bridging natively.
Remote Home Assistant integration. A specific integration that connects one Home Assistant instance to another. Entities from the remote instance appear in the local instance. Useful for operations where the central instance wants direct visibility into remote instance entities; works well for modest numbers of sites.
Cross-site automation through MQTT. Each site's Home Assistant publishes status (zone conditions, alerts, operational state) to the central MQTT broker. The central Home Assistant or dashboard subscribes, synthesizes a cross-site view, and can trigger automations. Automations that act on cross-site data stay at the central level; local automations continue to operate autonomously at each site.
Shared data through InfluxDB. Each site's Home Assistant writes to a central InfluxDB (or a per-site InfluxDB with aggregation). A central Grafana instance reads from the unified InfluxDB and produces cross-site dashboards. The unified history enables comparisons, benchmarking, and analysis across sites.
Cloud coordination. For operations where local network between sites is not reliable or not available, cloud-based coordination fills the gap. Nabu Casa, a central cloud server, or specialized IoT platforms can relay messages between sites even when direct site-to-site connectivity is missing.
What stays local. Each site's critical automations — climate control, irrigation, lighting — run on the local Home Assistant at that site. If inter-site communication fails, each site continues operating autonomously. Only the cross-site coordination (unified dashboards, aggregated alerts, cross-site analysis) depends on the coordination layer.
The pattern most agricultural operations land on. Each site has a graybox host running Home Assistant plus its local services (InfluxDB for site history, Grafana for local dashboards, local MQTT broker). The site hosts talk to each other and to a central coordination server; the coordination server runs a central Grafana that aggregates across sites and a central Home Assistant that provides cross-site automation and alerting. Local operation continues when coordination is down; coordinated visibility when it is up.
Architecture C: Fully independent instances.
No automatic coordination; the grower's attention is the coordination layer.
When this fits. Operations where sites are genuinely separate — different crops, different staff, different seasonal patterns. The grower accesses each site's Home Assistant through remote access per site; the dashboards are per-site; the alerts come from each site independently.
The advantage. Simplicity. No coordination layer to design, configure, maintain. Each site's installation is self-contained.
The limit. No unified view. The grower checking on the operation has to look at each site separately. Cross-site questions ("how are DLIs across my three sites this week?") require manual collation.
Hybrid patterns. Some operations that use Architecture C for control add a lightweight aggregation layer for visibility only — a central Grafana reading each site's InfluxDB, for example, without any control integration. The separation of control from visibility can produce a simple architecture that still provides some cross-site insight.
Networking between sites.
The infrastructure layer.
Site-to-site VPN. The common pattern for connecting sites privately. Each site's network extends to the others through the VPN. Site-to-site VPN can run on the router (if the router supports it), on a dedicated device per site, or on the Home Assistant host itself. WireGuard and similar modern VPN technology make this reasonably straightforward.
SD-WAN for larger operations. For operations with many sites or complex routing needs, software-defined WAN tools (Tailscale, ZeroTier, and others) provide mesh VPN networks. Each site becomes a node in the mesh; routing between them is handled by the overlay network. Simpler for complex topologies than manual VPN configurations.
Direct connections where available. For sites close enough, point-to-point wireless links (dedicated equipment between the sites) provide high-bandwidth, low-latency connectivity without cellular or internet. Expensive but reliable.
Cellular backup for rural sites. Sites with primary internet over cable or fiber benefit from cellular backup. A cellular router that takes over when the primary link fails keeps the site connected during outages. For multi-site operations where the inter-site link depends on each site's internet, cellular backup at each site maintains coordination during provider outages.
Latency and its implications. A local Ethernet network has latency of a millisecond or less. A VPN across the internet typically has 20-100 milliseconds of latency. This matters for real-time coordination (a single-instance architecture across the internet is sluggish in a way a local-network architecture is not) but rarely matters for monitoring and coordination (Grafana dashboards updating every few seconds do not notice 50 ms).
Bandwidth considerations. Multi-site deployments can consume meaningful bandwidth if camera feeds, continuous MQTT traffic, or InfluxDB writes flow between sites. Planning for the bandwidth budget prevents surprises.
Centralized dashboards and alerting.
The visibility layer across sites.
Central Grafana with per-site InfluxDB data. Each site's InfluxDB is either replicated to a central instance or queried remotely by a central Grafana. Grafana dashboards can show data from multiple sources simultaneously — a temperature graph with lines for each site, a DLI comparison across all zones, cross-site alerts that summarize the state of the whole operation.
Central Home Assistant as an aggregation layer. A coordination-layer Home Assistant that does not directly control any site's equipment but subscribes to cross-site data via MQTT or Remote Home Assistant. Automations at this level produce cross-site alerts ("two sites have high temperatures in the same hour"), aggregate metrics, and unified notifications.
Morning briefing across sites. A morning briefing automation (per the patterns in AI-Powered Automations) at the coordination level produces a single summary covering all sites. The grower gets one briefing, not three — more useful for the single-operator multi-site case.
Per-site dashboards remain primary. Staff at each site typically continue using the local dashboard at that site. The central dashboard is for the grower overseeing multiple sites; it does not replace the local view.
Alert routing by site. Alerts from Site A may need to reach Site A's local staff, not just the central grower. The coordination layer can route alerts — local alerts to local staff, critical alerts to the central grower as well. This requires specific configuration but is worth building for operations with distributed staff.
User access across sites.
Authentication and authorization across installations.
Per-instance users is the default. Each Home Assistant instance has its own user database. A grower who is owner at Site A is an entirely separate user account at Site B. Authentication happens per site.
The friction. Multi-site operators have multiple sets of credentials to manage. For a single grower, a password manager covers this. For operations with multiple staff across sites, the friction compounds — each staff member has a set of accounts to manage.
External identity providers. Home Assistant supports authentication through external identity providers (Authentik, Authelia, LDAP, and others). One identity provider serves multiple Home Assistant instances; users authenticate once with the provider and access any site they have permission for. Substantial configuration effort; significant simplification for operations with staff across sites.
Role mapping across sites. An operation with the same staff across multiple sites typically wants their roles consistent — admin at one site, admin at all sites; operator at one, operator at all. External identity providers with role claims handle this; without external IdP, the consistency is maintained manually.
Access logging across sites. With separate Home Assistant instances, access logs are per-site. A unified view of who-logged-in-when-from-where requires aggregation — typically by shipping each site's authentication events to a central logging system.
Backup and update coordination.
The operational practices from Phase 9 applied to multi-site.
Per-site backups. Each site's Home Assistant backs up independently. The Phase 9 backup discipline applies per site — local backup, offsite backup, 3-2-1 rule, test restore.
Central backup aggregation. Some operations centralize backups by having each site's backups replicated to a central location. The central location then backs up offsite according to the broader strategy. Simplifies the offsite-copy part of the 3-2-1 rule for multi-site.
Update staging across sites. The staging pattern from the Updates page applies well to multi-site — use one site (or a dedicated staging environment) as the test before updating the others. An update that works on Site A for a week can be rolled to Site B with confidence.
Version consistency across sites. Sites running different Home Assistant versions have different capabilities and different breakage risks. Some operations deliberately keep all sites on the same version (harder); some let them drift (easier but accumulates differences). The right answer depends on how much cross-site automation depends on version consistency.
Update windows by site. Critical automation times differ across sites. A site in flowering mode this week should not be updated; a site between crops is a safe update candidate. Coordinated update scheduling across sites respects each site's operational constraints.
Common failure modes.
Specific multi-site problems from real deployments.
The single-instance architecture that suffered from network drops. A three-greenhouse operation ran one Home Assistant with the main house connected to satellites via WiFi bridges. Network drops caused remote sensors to appear unavailable for minutes at a time; alerts fired; automations that relied on those sensors failed. Fix: for sites with unreliable interconnection, federated instances with local autonomy work better than single-instance.
The federated setup where coordination layer failed. MQTT broker at the coordination site crashed; cross-site dashboards stopped working; the owner did not know anything was wrong at any site until manually checking each. Fix: monitoring of the coordination layer itself; alerts when cross-site visibility is lost; clear escalation to per-site access during coordination outages.
The multi-site deployment without version discipline. Sites drifted to different Home Assistant versions over time. Cross-site automations broke when one site updated to a version with behavior changes. Fix: decide whether version consistency matters; if it does, maintain it; if it does not, avoid cross-site automations that depend on version-specific behavior.
The backup strategy that covered only one site. The operation had a central backup server replicating Site A; Sites B and C did not have offsite copies. A hardware failure at Site B lost the operation several weeks of configuration work. Fix: 3-2-1 applied per site; offsite for every site, not just the central one.
The remote access that only worked for the central site. The grower could reach the central Home Assistant from outside the network; Sites B and C did not have their own remote access configured. During an emergency at Site C, the grower could not investigate without driving there. Fix: remote access configured per site, with each site's access secured per the Remote Access page.
The security policy that was stronger at some sites than others. Site A was locked down with strong passwords, 2FA, and network segmentation. Site B had a weak default password and no 2FA because it was "only a secondary site." Attacker compromised Site B and pivoted into Site A's network. Fix: consistent security across sites; weaker security at any site is the weak link for all.
The alert storm across sites during a common-cause failure. A regional power outage affected two sites simultaneously; each site generated its own alerts; the owner's phone was swamped with dozens of notifications. Fix: coordination-level alert aggregation; a regional-condition detection that suppresses per-site alerts during common-cause events.
The site that was not included in monitoring. A new site was added; its Home Assistant was set up; the central monitoring was not updated to include it. A serious condition at the new site went undetected for hours. Fix: a checklist for adding new sites that includes monitoring integration; the monitoring layer is not complete without every site covered.
The dashboard that showed misleading cross-site data. A central dashboard showed "all temperatures in green" because one site's sensors were offline and showing stale green values. Actual conditions at that site were out of range; the dashboard misrepresented. Fix: dashboards that explicitly handle stale-data cases; freshness indicators per site; alerts on data staleness, not just on threshold crossings.
The coordination layer that became a single point of failure. Every site's local operation continued when the coordination layer failed, but the owner's usual workflow went through the central dashboard. During the coordination outage, the owner felt blind even though the sites were operating normally. Fix: ensure local per-site access is still straightforward when coordination is down; exercise the "coordination is down" workflow periodically.
What not to do.
Patterns to avoid.
Don't force single-instance across poor networks. If the inter-site link is not reliable, a single-instance architecture produces persistent problems. Accept the federated pattern where it fits.
Don't skip per-site backup discipline. Each site is a site. The 3-2-1 rule applies to each; none should rely entirely on another site's backups.
Don't create cross-site dependencies that defeat the point of multi-site. An automation at Site A that depends on data from Site B via the coordination layer fails when coordination fails. Cross-site automations should be non-critical; local automations should work standalone.
Don't let security discipline vary between sites. The weakest site is the weakest link. Consistent security across sites prevents attackers from pivoting from a weaker site to a stronger one.
Don't make the coordination layer the only access path. Local per-site access must work. The coordination layer is for convenience and cross-site visibility, not for replacing direct site access.
Don't skip monitoring the coordination layer. If the coordination layer fails silently, the operation loses cross-site visibility without knowing it. Monitor the coordination; alert when it fails.
Don't deploy multi-site without a plan for adding sites. Operations that add sites often end up with inconsistent configurations — each site was set up independently, each slightly different. Document the pattern; follow it when adding sites.
Don't ignore the human coordination layer. Multi-site operations often involve multiple people; the Home Assistant coordination alone does not coordinate the humans. Communication protocols, on-call rotations, incident response procedures — these are the human layer that Home Assistant does not replace.