Skip to content

CONCEPT Cited by 1 source

Local-first architecture

Definition

Local-first architecture is a system-design posture in which all state, all processing, and all control live on user-owned hardware — not on a vendor's cloud — and in which offline operation is a functional requirement, not a degraded mode. The cloud, if present at all, is an opt-in accessory for remote access or AI fallback; no core function may depend on it.

From the ingested source: "It's crazy that we need the internet nowadays to change your thermostat." The local-first stance inverts the consumer-IoT default (cloud-centric with on-device as the degraded fallback) — the home "is the data center." (Source: sources/2025-12-02-github-home-assistant-local-first-maintainer-profile)

What it forces

Compared to cloud-centric designs, local-first has to run the entire workload on-box on whatever the user's hardware is — often something as small as a Raspberry Pi. The workload the source enumerates for a home-automation runtime:

  • Device discovery — protocol-by-protocol (Zigbee, Z-Wave, Matter, vendor APIs) on the LAN, with no cloud directory.
  • Event dispatch — every sensor reading, state change, and scheduled check flows through the runtime's event bus.
  • State persistence — durable store for entity state + historical traces, locally.
  • Automation scheduling — declarative triggers-and-actions evaluated against the local event stream.
  • Voice-pipeline inference — on-device if local, cloud only if the user explicitly opts in (Assist's Stage-2 fallback; see patterns/deterministic-intent-with-ml-fallback).
  • Real-time sensor reading — no network RTT in the loop.
  • Integration updates — handled locally; vendor cloud is not a delivery channel.
  • Security constraints — the runtime is itself on the trust perimeter; no vendor-cloud intermediary to lean on.

"This architecture forces optimizations few consumer systems attempt. If any of this were offloaded to a vendor cloud, the system would be easier to build." Named low-level consequences: SSD wear levelling on the Pi, MQTT throughput, Zigbee network topologies — "Everything… becomes a software challenge."

Why it's a hard constraint, not a feature

Framed as engineering with no safety net — the system must keep working offline by design. There's no fallback to "degraded cloud mode" because the local-first posture is the point.

Two failure modes local-first explicitly addresses (named in the source):

  • Vendor cloud lifecycle risk. Commercial IoT pivots to cloud-centric models periodically kill products. "If some manufacturer turns off the cloud service… that turns into e-waste." (Cited example: Google Nest deprecations.) A local-first design survives vendor cloud shutdown with zero change — the device keeps working.
  • Privacy / data sovereignty. No event data, audio, or telemetry leaves the home by default. Users opt in explicitly per-integration if they want cloud AI, remote access, etc.

Relationship to digital sovereignty

Local-first and concepts/digital-sovereignty share an underlying "infrastructure control" axis — the demand that a workload keep running under user-controlled conditions. They differ on threat model and scope:

Axis Local-first Digital sovereignty
Scope Consumer / home Enterprise / regulatory
Threat model Vendor cloud shutdown, privacy loss Geopolitical / regulatory withdrawal of access
Actor Individual homeowner Government, regulator, legal entity
Hardware User-owned consumer HW (Pi, hub) Sovereign-cloud partition, air-gapped DC
Canonical instance systems/home-assistant AWS European Sovereign Cloud, AWS GovCloud

Both refuse to treat "the cloud" as an opaque infrastructure commodity; both demand infrastructure control as a first-class requirement.

Relationship to event-driven architecture

Home Assistant's runtime is a consumer-edge / single-host instance of concepts/event-driven-architecture: every sensor reading, state change, and scheduled check is an event, and automations are triggers over the event stream. Distinct from the managed-bus-with-subscribers EDA shape (EventBridge, Kafka topics with cross-service consumers) — there is no inter-service bus because there are no services, just one runtime on one host.

Open questions left unanswered by the source

  • Sync / multi-device coordination. How does local-first scale to users with multiple Home Assistant instances across rooms / homes? Not addressed.
  • Remote access. The source doesn't disclose how Home Assistant handles the cloud-adjacent use case of mobile access from outside the LAN (Nabu Casa? reverse tunnel? VPN-only?).
  • Update delivery. If the cloud isn't a delivery channel, how are integration updates delivered locally? Not detailed in the ingested source.
  • Trust root + attestation. Who signs firmware? How is integrity verified on a hub the user built themselves? Not disclosed.

Seen in

Last updated · 200 distilled / 1,178 read