What Memory Limit Should You Set for Home Assistant?

There is no single correct Home Assistant memory limit. Set the boundary from your own measured peak, leave usable RAM for the host and other containers, and treat any OOM kill as evidence that the limit or workload needs investigation.

On a shared home server, an idle reading is not enough: Recorder work, backups, integration reloads, dashboards, and a busy whole-home automation sequence can produce different peaks. The safe path is to record a baseline, choose a reversible limit above the verified workload peak, confirm that the host still has headroom, and retest the original busy period before making the setting permanent.

Start With Peak Use, Not a Generic RAM Number

Measure the Home Assistant container and the host at the same time for several ordinary days. Include a restart, a backup, a database purge or repack if you use one, dashboard activity, and the busiest automation period you can reproduce safely. Record the container peak, host available memory, swap activity, and whether response time changes.

A memory limit is a cgroup boundary, not a performance target. When a container crosses a hard boundary, the kernel can terminate a process; an exit code of 137 together with an OOM-killed state is the useful signature. This is why peak observed usage matters more than an average or a copied recommendation.

If memory rises during a task and then settles, size for that repeatable peak plus working room. If anonymous memory climbs for hours without returning after the workload ends, stop sizing and investigate a leaking integration, custom component, or version regression. A larger ceiling may delay the crash without correcting it.

Reserve Memory for the Host and Every Co-Hosted Service

List the services that must remain responsive when Home Assistant is busiest: the operating system, Docker, a database, MQTT, DNS, dashboards, media services, and backup jobs. The limit must protect those services as well as Home Assistant; giving one container almost all installed RAM simply moves the failure to the host.

Compare Home Assistant's peak with host available memory during the same window. Cache that can be reclaimed is not equivalent to application memory, and swap activity can make a system look alive while device control becomes slow. If the host loses headroom before Home Assistant reaches its peak, reduce overlapping jobs or move a service before tightening the Home Assistant ceiling.

This is a capacity decision, not just a Docker setting. The related ZimaSpace guide on measuring Home Assistant beyond warm cache explains why a repeatable cold and busy workload gives a more trustworthy baseline than a convenient idle snapshot.

Apply a Reversible Limit and Verify That It Is Enforced

Add the memory setting in the configuration that actually recreates the container, such as your Compose file or orchestration UI. Avoid relying on a one-time live update if the next deployment will discard it. Save the previous configuration so you can restore it immediately.

After recreation, inspect the running container and confirm that the configured limit is visible. Then watch container usage, host available memory, swap, restart count, and latency. A displayed setting that is not enforced by the host cgroup gives false confidence, especially in nested virtualization.

If the container restarts, do not raise the limit automatically. Check whether the runtime reports OOMKilled and exit 137. If not, investigate another shutdown path. If yes, compare the timestamp with the workload: a repeatable short peak suggests insufficient working room, while steady growth suggests a leak or runaway integration.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Retest Under the Original Busy Home Assistant Workload

Repeat the exact scenario used for the baseline: reload the same integrations, open the same dashboards, run the same whole-home control sequence, and include the same backup or Recorder activity. Changing the workload would only prove that a lighter system fits.

A passing result means the container stays below the boundary without OOM events, the host retains usable memory, swap does not create control lag, and automations complete at their normal speed. Restart twice and check again after the next scheduled background job so the result survives recreation and time-based work.

Roll back the new limit if device control becomes unreliable, the container enters a restart loop, or host pressure remains severe. Escalate to integration isolation or version comparison when memory keeps climbing after the triggering workload ends; at that point, limit tuning is no longer the primary repair.

FAQ

Should Home Assistant always have a hard memory limit? On a shared Docker host, a tested boundary can protect other services. A dedicated HAOS machine or VM is sized differently, so do not copy a container limit into a VM allocation without measuring the full guest.

Is high used memory automatically a leak? No. Cache and short workload peaks can be normal. Look for anonymous memory that keeps growing, OOM events, restart loops, or worsening latency after the workload ends.

Should you disable swap? Not as a first move. First learn whether swap is hiding host pressure or preventing abrupt failure, then change it only with a tested rollback path and enough physical RAM for the full workload.