Use separate Home Assistant accounts for household members; keep a shared account only for a fixed communal device whose limited purpose and owner are documented.
One family login feels convenient until notifications, dashboards, device tracking, audit clues, saved sessions, and revocation all point to the same identity. Create personal standard accounts first, keep administration separate, and test what each role can actually see and change. Treat a wall tablet as a device identity, not as a substitute for every person.
Separate People, Users, and Shared Devices
List each household member who needs interactive access, each administrator, service integrations, and fixed shared devices such as wall tablets. Record whether the identity needs presence tracking, personal notifications, configuration access, or only a communal dashboard.
Using per-person accounts and dashboards keeps personal sessions distinct. Verify current permissions in the actual installation rather than treating dashboard selection as full security isolation.
A person should receive a personal account; an administrator should also have an identifiable personal login. A fixed display may use a separate limited device account when automatic access is required and its physical location is controlled.
Compare Accountability, Revocation, and Experience
With personal accounts, sessions can be removed for one user, preferences remain separate, and activity can be interpreted with more confidence. With one shared login, a password change, compromised device, or household departure affects everyone and provides no reliable actor distinction.
Choosing separate household accounts trades one-time setup for independent revocation and preferences; the decision should follow role needs rather than household size alone.
Choose shared access only when the endpoint is communal, limited, and cannot reasonably carry an individual's session. Do not reuse that account on personal phones or grant it administrator rights for convenience.
Apply Least Privilege and Test Real Actions
Create standard accounts for household members, reserve administrator rights for people who maintain integrations and configuration, and set a deliberate default dashboard. Test ordinary control, history visibility, settings access, notification routing, and sign-out behavior from each role.
The distinction between presentation and authorization is developed in the household identity model. Use it when a hidden view might otherwise be mistaken for an access-control guarantee.
If a standard user cannot perform a required household task, grant the smallest supported role change or redesign that task; do not make every account an administrator. If sensitive entities cannot be isolated as required, treat that as a product boundary and adjust exposure.
Verify Device Loss and Household Change
Sign out one test account, revoke its sessions, and confirm other household accounts continue working. Then test a lost-phone scenario and a departing-user scenario without changing the shared device or administrator credentials.
For a communal display, restart it, verify it returns only to the intended limited dashboard, and confirm its credentials are not reused elsewhere. Keep a named administrator responsible for updates and revocation.
Stop when every person and shared device has a named role, minimum necessary access, and an independent removal path. Escalate when the current permission model cannot protect sensitive controls or history; do not promise isolation that the tested role cannot enforce.
Review the account list after household changes and at a regular maintenance interval. Remove abandoned device sessions, confirm current administrators, and keep the communal account limited to the single endpoint it was created to serve.
Support & Tips
More to Read

How to Optimize Immich Database Connections for Concurrent Containers
Do not raise max_connections first. Measure Immich sessions, total every container's demand, preserve admin headroom, and tune only the proven bottleneck.

How to Prevent Duplicate Jobs or Imports in Immich
Separate repeated jobs from duplicate assets. Use one canonical ingestion path, control retries and path changes, then test re-entry on a small cohort.

How to Repair Immich After Its Database Volume Fills Up
Never delete PostgreSQL WAL to free space. Stop Immich writes, preserve database state, add safe capacity, recover PostgreSQL, then prevent recurrence.

