Every building automation proposal eventually reaches the same question: why not put everything in the cloud? The answer is not nostalgia for on-premise servers. It is a set of operational, security and commercial realities that show up after handover.
What “local-first” actually means
Local-first means the control logic, schedules, interlocks and history live in the building. The cloud may provide remote access, portfolio reporting or software updates, but it is not on the critical path for comfort, safety or basic operation.
This is not the same as “offline only”. A local-first system can use cloud services. It simply does not depend on them to keep the lights on.
Four reasons it matters
1. Network outages are normal
ISP outages, router failures, construction damage and certificate expiry happen. A building that loses HVAC control because a cloud tenant is unreachable is a building with a design defect.
2. Latency is a control variable
A cross-system interlock that depends on a round trip to a distant data centre is slower and less predictable than one that runs on the local controller. For access-to-lighting or alarm-to-CCTV sequences, that difference is visible.
3. Data ownership is easier to defend
Building data describes occupancy, energy use and equipment performance. Keeping it local reduces the number of processors, jurisdictions and contractual relationships involved. Export through open interfaces keeps it portable.
4. The building outlives the vendor
A building operates for decades. Cloud services, startups and pricing models do not. Local control and documented open interfaces give the owner a path that does not depend on a single vendor's continued commercial success.
What to keep local
| Function | Local? | Why |
|---|---|---|
| Safety and equipment protection | Yes | Must work during any network failure. |
| Schedules and setpoints | Yes | Core comfort and energy performance. |
| Cross-system interlocks | Yes | Latency-sensitive and operationally critical. |
| Alarm annunciation | Yes | Operators need the alarm even when the WAN is down. |
| Long-term history | Local + export | Owner-controlled retention; export for analytics. |
| Portfolio benchmarking | Cloud optional | Useful, but not on the critical path. |
| Remote access | Cloud optional | Convenience, with 2FA and audit logging. |
Security is not binary
“Local” is not automatically secure, and “cloud” is not automatically unsafe. The controls matter more than the location: network segmentation, role-based access, two-factor authentication, patching, backup and an audit trail.
A local-first architecture does make some controls easier. The attack surface is smaller when the building does not need an inbound internet path to run. Remote access can be brokered, logged and revoked without exposing the control network directly.
Ask what the building does when the internet is unavailable for 24 hours. If the answer is “the vendor's cloud keeps working”, ask what happens when it does not.
What to write into the specification
- Control sequences must run locally and continue during a WAN outage.
- Remote access must use two-factor authentication and be logged.
- History must be stored locally and exportable in an open format.
- Configuration backup and restore must be documented and tested.
- The owner must retain administrative control of accounts and data.
The takeaway
Local-first is not anti-cloud. It is a statement about where the building's critical functions live. Put control and history on site, use the cloud for convenience and reporting, and make the boundary explicit in the contract.
