How Many Concurrent Users Can Home Assistant Handle Before It Slows Down?

Eva Wong

IceWhale author

Eva Wong is the Technical Writer and resident tinkerer at ZimaSpace. A lifelong geek with a passion for homelabs and open-source software, she specializes in translating complex technical concepts into accessible, hands-on guides. Eva believes that self-hosting should be fun, not intimidating. Through her tutorials, she empowers the community to demystify hardware setups, from building their first NAS to mastering Docker containers.

How Many Concurrent Users Can Home Assistant Handle Before It Slows Down?

Home Assistant does not have a useful universal answer such as “20 users” or “100 users.” A logged-in account that is idle creates a different workload from a wall tablet rendering a complex dashboard, a phone opening History, or several users watching camera cards while thousands of entities update.

Size concurrent use by measuring connected clients and the work each client causes. The practical limit is the point where your representative dashboards, WebSocket updates, server actions, and network path begin missing the response target you consider acceptable.

Count Connected Clients, Not Just User Accounts

Creating 100 accounts does not mean 100 simultaneous sessions. Conversely, one person can have a browser, phone, tablet, and kiosk connected at the same time.

Home Assistant's WebSocket integration can expose sensor.connected_clients as the current number of connected WebSocket clients. Use that number as a concurrency signal while you reproduce the workload.

Record the client count together with server CPU, memory pressure, network throughput, and action latency. A connection count without the workload behind it is not a capacity result.

Frontend Cost Depends on State Updates and Dashboard Work

The frontend establishes a WebSocket connection and keeps Home Assistant state synchronized with the browser. Each client also has to render the dashboard it opens, so client hardware and custom cards can become limits before the server does.

The current frontend architecture describes how the frontend receives core state and additional subscriptions through the WebSocket API. A busy installation therefore creates continuous update work after the initial page load.

Benchmark the actual dashboard mix used by the household instead of opening an empty test page on every client.

High Entity-Update Rate Can Hurt Clients Before User Count Looks Large

A system with thousands of frequently changing sensors can send far more frontend work than a larger user population viewing mostly static entities. This is especially visible on older tablets and low-power wall panels.

A Home Assistant issue documented a case where large volumes of entity updates overwhelmed dashboard clients even when the visible dashboard itself was simple.

That does not define a universal threshold, but it shows why “users” is the wrong single unit. Measure updates per second and client responsiveness beside connection count.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

There Is No Published Household-Scale Maximum to Copy

Community questions about unusually large deployments illustrate the uncertainty. A discussion about roughly 200 users found no clear supported maximum and treated that scale as an unusual use case that should be tested rather than assumed.

For a normal household, this means you do not need to chase a vendor-style maximum-session number. For a community gate, shared building, lab, or other high-user deployment, Home Assistant may not be the right identity and access platform even if the server can technically sustain the connections.

The ZimaSpace concurrent-workload sizing method applies here: capacity should be tied to the busiest realistic overlap, not to total registered accounts.

Run a Step Test Until One Metric Repeats the Failure

Step	Measure	Stop condition
Add active clients in small groups	Connected clients	Representative concurrency reached
Open real dashboards	Initial render and interaction delay	Repeated user-visible lag
Generate normal entity traffic	WebSocket/update load	Clients cannot keep up
Trigger common actions	Server action-to-device latency	Control latency rises materially
Repeat at peak	CPU, memory, network, client load	Same limiting layer appears again

Choose capacity one step below the first repeatable failure point and leave margin for backups, updates, camera traffic, and unusual bursts. If only one old tablet slows while server actions remain fast, replacing the server may not increase usable concurrency.

FAQ

Do 20 Home Assistant user accounts equal 20 concurrent users?

No. Accounts are identities; concurrency is active client connections and the work those clients create. One user can have several clients, while many accounts can be completely idle.

Will simpler dashboards always let more users connect?

They can reduce client rendering work, but server capacity also depends on entity-update rate, WebSocket traffic, history queries, cameras, network path, and background services. Measure the full workload.