Runtime State vs Persistent State in Home Assistant: What Must Survive Restart?

Home Assistant “state” is not one thing. The running process has an in-memory State Machine that represents what entities report now, while persistent configuration and registries identify what should exist after restart. Recorder keeps historical observations, and selected entity platforms can save values specifically so those values can be restored later.

A reliable deployment therefore does not try to serialize every transient object in memory. It preserves the durable sources of truth and lets the new process rebuild live state from integrations, registries, restored values, and fresh device reports.

The State Machine Is a Runtime View of the Current World

Home Assistant Core keeps current entity states in its State Machine and emits events when those states change. That current view belongs to the running Core process.

The Core architecture documentation describes the State Machine as the component that tracks current states and fires state_changed events. The Event Bus, Service Registry, and Timer are runtime components around it.

After restart, the State Machine is populated again. A device that has not reconnected can therefore be unavailable even while its old observations remain safely stored in Recorder.

Entity Registries Persist Identity, Not Live Device Truth

Home Assistant needs to recognize the same entity across restarts so user customizations, entity IDs, names, areas, and other settings do not disappear every time an integration reconnects.

The entity registry exists because Home Assistant needs durable entity identity across restarts to retain customizations and track known entities. That registry entry does not mean the current sensor reading is automatically current after boot.

Think of identity and live value as separate records: the registry answers “which entity is this?” while the integration answers “what is it reporting now?”

Some Entity Values Are Intentionally Saved for Restoration

Certain entities—especially helpers and stateful software entities—benefit from restoring their previous value before a fresh external observation exists. Home Assistant has a dedicated persistent-state checkpoint for those entities.

The current save persistent states action explains that some entities restore their last value after restart and that Home Assistant normally checkpoints those values at startup, every 15 minutes, and at shutdown.

This is selective persistence. It should not be confused with treating every physical device state as authoritative forever. A restored value can be useful during startup, but an integration should still converge on fresh device truth when available.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Recorder History Persists Observations, Not the Running Process

Recorder stores state changes and events for historical views, analytics, and statistics. That database can survive many Home Assistant restarts while the runtime State Machine is recreated each time.

A History query answering “what was the temperature at 3 p.m.?” belongs to historical persistence. A live automation asking “is the door open now?” depends on the current runtime state and integration path.

The distinction explains why deleting or corrupting Recorder can remove history without necessarily erasing automations, users, and integration configuration, while losing the configuration directory can destroy identity and setup even if an old history database still exists.

The Deployment Must Persist the Files That Recreate These Layers

Containerized Home Assistant adds one more boundary: the runtime image can be replaced, while the configuration mount and external dependencies must survive outside it. The mount needs to preserve Home Assistant configuration, registry storage, secrets references, and the database if Recorder is local.

The ZimaSpace article on Home Assistant persistent data roles covers recovery scope. The runtime-versus-persistent distinction explains why those files matter: they are the inputs from which the next process reconstructs the household.

Use the Persistence Layer That Matches the State Role

The safe rule is to persist the identity, configuration, recovery data, and state that Home Assistant intentionally treats as durable. Let transient runtime state be rebuilt. That produces a cleaner restart model than assuming every value in memory should survive unchanged.