Apply patch updates automatically on Home Assistant OS

[frenck]

Problem statement

On Home Assistant Operating System, Core updates are user-initiated today. A new release lands in the user's Updates panel, and nothing happens until that user opens the panel and clicks Install. For an engaged maintainer this is fine. For everyone else it is not.

Releases come in two shapes. Major releases ship monthly, on the first Wednesday of each month, with the last week of the cycle focused on beta testing as documented in the release FAQ. They contain new features, integration changes, and the occasional breaking change. Patch releases ship on a weekly cadence, typically on Fridays, between majors. Recent examples: 2026.4.1 (Fri April 3), 2026.4.2 (April 11), 2026.4.3 (Fri April 17), 2026.4.4 (Fri April 24). Patches contain bug fixes only, including the security and stability fixes that should land on every instance. Major releases benefit from user attention. Patch releases do not need it; they are designed to be safe to install.

The current model treats every patch as something a user has to act on. During the stable period of a major release, bug fixes and security fixes ship as weekly Friday patches. They reach engaged maintainers within a day. They reach less-engaged users only when those users happen to open the Updates panel and click Install. By the time the next major lands, an instance that has not been touched is still sitting on the .0 release, having missed every fix written specifically for it.

1. Patch releases reach only engaged maintainers during the stable period. Users who maintain Home Assistant as a hobby update the day a patch drops. Users who treat it as an appliance miss the bug fixes and security fixes that were written, tested, and shipped explicitly for the version they are running.
2. Manual install for safe-by-design patches is friction without payoff. Each weekly patch is a context switch: notice the badge, open the Updates panel, click Install, wait for the restart. Patches are bug-fix-only by design. The manual gate adds maintenance work without adding user agency. A user who wants to vet a change still wants to vet a major release; they do not need to hand-install every Friday's bug fix.
3. The default punishes the less-engaged user. A new user installing Home Assistant for the first time should not be expected to learn release management as part of the onboarding curve. The default should be: bug fixes and security fixes apply themselves during the stable period, while majors stay in the user's hands.
   This bet is blocked on End-to-end test Home Assistant Core before release. We cannot ship a default-on auto-update policy for Core patches without first guaranteeing that the Core image we publish each Friday actually boots and works. Once that gate is in place, the appetite for automating patch installation is real.

Reducing the maintenance burden of running a Home Assistant instance is a direct lever on the kind of user who can adopt Home Assistant and stick with it. This bet alone takes the manual-update touchpoint from weekly Fridays down to roughly twelve a year, one per major release. This maps to Make Home Assistant More Approachable.

Community signals

The desire for automatic updates is one of the longest-running threads in the Home Assistant community. WTH ("Month of What the Heck?!") posts surface the request every cycle, and several community members have built their own patch-only auto-update automations because the platform does not.

WTH posts (recurring across years)

• WTH can't home assistant auto-update? (October 2022). Asks for a configurable maintenance window where Core, OS, and Apps auto-update.

• WTH there is no automatic updates? (December 2024). Frames manual updates as friction relative to other consumer devices.

• WTH, why doesn't HA update automatically? (December 2024, 19 posts). Notes Home Assistant becoming more accessible for less technical users while still requiring manual updates to Core, Supervisor, and OS.

• WTH are there so many manual updates (December 2024). Frames the cost of managing multiple instances with frequent manual touches.

• Auto update feature / schedule / task in automations (December 2024). Points out that automations can detect available updates today but cannot install them.
  Feature requests (with engagement)

• Scheduled auto-update for Home Assistant (September 2022, 124 posts). The most engaged thread on the topic, paired with a community-built blueprint for scheduled auto-update.

• Auto Update feature for Core/Supervisor. Explicitly Core and Supervisor scoped feature request, multi-page discussion.

• Automatic OS and Core Updates. Earlier feature request covering OS and Core together.

• Feature Request: Implement User-Configurable Auto-Update Options for HAOS (April 2025). Asks for the configurability shape (cooldown, schedule, opt-out) this opportunity proposes.

• Automatic updates in homeassistant (April 2026, 30 posts). Recent active thread on the same topic.
  Community-built patch-only solutions (proof of pre-shipping demand)

• HA Core auto update Patch version. Community-built automation that fires when an update is detected, checks whether only the patch component changed, and installs only if so. The exact pattern this opportunity proposes to ship natively.

• Automation to auto-update to same version minor release e.g. .1 -> .2 (March 2024). Same pattern, different author.

• Update Scheduler (November 2023). Adjacent: scheduling logic applied to update install timing.
  Adjacent: users asking for the opposite (delay, not auto)

• Is it possible to keep my HA on a delayed update schedule? (July 2024). A user asking to lag releases by a month for stability. Relevant because it confirms the design space includes both sides: faster (auto-on) and slower (deferred). The settings surface should make both possible.

The pattern across these threads is consistent: users want to set a policy once and stop thinking about updates. The split is on whether to lean automatic or manual; both sides agree the current "every release is a manual touch" model is wrong.

Scope & Boundaries

In scope

• Automatic installation of Core patch releases on Home Assistant OS. A HAOS user on 2026.5.0 may auto-update to 2026.5.1, 2026.5.2, and so on. Major releases stay user-initiated in this bet. The Container install type is explicitly out of scope (see below).
• Default on for new installations. A first-time setup enables automatic patch updates as part of the onboarding default.
• Default off for existing installations, with a one-time prompt. Existing instances keep their current behavior until the user explicitly opts in. The next major release surfaces a one-time prompt offering to enable it, with a clear summary of what will change.
• User-configurable schedule. A cooldown after a release is available, a preferred time-of-day window (for example, 5 AM local), and optional weekday restrictions. An "immediately" option for users who want zero cooldown. A fully-disabled option.
• Clear messaging about restart impact. Enabling auto-update means Home Assistant will restart on its own. Automations may be briefly interrupted while the restart happens. The setting copy and the onboarding flow have to say this plainly.
• A new automation trigger: Home Assistant was automatically updated. Fires after a successful auto-update, with the previous and new version available to the trigger context.
• A blueprint shipping the canonical example. Send a notification on auto-update. Users can clone or replace it with whatever announcement, log entry, or post-update action they prefer.

Not in scope

• Auto-updates for major releases. Majors come with their own design challenges that warrant their own bet: handling backward-incompatible changes, integration migrations, breaking-change surfacing, and how to communicate any of that to non-engaged users. That is a separate future opportunity. The first step this bet takes is reducing manual-update touchpoints from weekly Fridays to roughly twelve a year, one per major release.
• Auto-updates for OS, Apps, integrations, or HACS. Each has its own update flow and lifecycle. This bet is specifically about Home Assistant Core patch releases.
• The Container install type. This bet is HAOS-only. On Home Assistant Container, the user controls the Docker runtime, and Home Assistant cannot safely self-update across that boundary. Container users continue to receive Core patches via the existing distribution channels and apply them on their own schedule.
• Sibling bet: End-to-end test Home Assistant Core before release. That bet is the prerequisite for shipping this one safely. It does not live inside this scope.

Foreseen solution

Phase 1: Settings and policy for Core patch updates. A new section under Settings, System, Updates that exposes the auto-update policy specifically for Home Assistant Core patch releases. The form covers: enabled or disabled, cooldown, time-of-day window, weekday selection, and the "immediately" shortcut. The default for new installations is enabled with a sensible default schedule (a short cooldown of a few days, a quiet-hours time window). The default for existing installations stays disabled.

Phase 2: One-time prompt for existing users. On the first major release after this ships, existing instances surface a one-time prompt offering to enable automatic patch updates. The prompt explains what will change, including the restart-and-brief-interruption messaging. The user picks enable, decline, or dismiss-for-now.

Phase 3: Trigger and blueprint. A new automation trigger fires when Home Assistant Core has just been automatically updated, exposing the previous and new version. We ship a blueprint that, when imported, sends a notification on auto-update with a release-notes link. Users can replace the action with whatever they prefer.

Phases 1 and 3 can run in parallel. Phase 2 depends on Phase 1.

Risks & open questions

• Prerequisite dependency. This bet is blocked on the end-to-end testing opportunity. Without it, automatic patch updates can ship a broken artifact to every default-on instance overnight. Question: do we sequence shaping to start only after the smoke test gate is live, or do we run shaping in parallel and gate execution?
• Patch releases are usually safe, not always safe. A patch release is bug-fix-only by policy, but policy slips. A bad auto-update reaching every default-on instance is the failure mode we have to design around. Mitigation lives in the smoke test gate and in a staged rollout, not inside this bet alone.
• Restart timing. A user actively interacting with their dashboard at 5 AM is unusual but possible. Do we defer the restart if the UI is in active use? Do we expose that as a setting, or hard-code it?
• Automation interruption. Restarts interrupt automations briefly. Most users will not notice; some will. The trigger and blueprint give them a hook, but the broader UX needs to acknowledge this honestly in copy and docs.
• Failure-mode UX. Automated rollback is already baked into the platform for failed updates. The open question is the user-facing story when an auto-update triggers a rollback: a persistent notification? A history entry surfaced in Settings? Auto-update temporarily disabled until acknowledged? Silent recovery is the wrong answer when the user did not initiate the update.
• Trust and auditability. Some users will want a record of what was updated when. Do we log auto-update events to the System log? Surface them in the Updates panel history?
• Open question: cooldown unit. Hours, days, or both? A multi-unit picker is more flexible but more complex. The simpler choice is days only, with a separate "immediately" option for users who want zero cooldown.

Appetite

Small to medium. Roughly one cycle of focused work spanning the patch-vs-major scheduling policy, the new automation trigger in core, and the frontend (settings UI, onboarding integration, one-time prompt). The blueprint is a small additional deliverable. Execution does not start until the End-to-end test Home Assistant Core before release prerequisite is in place.

Execution issues

To be populated once a bet is approved.

Decision log

Date	Decision	Outcome
2026-05-07	Created opportunity for betting table consideration.	Initial creation.

[tobbexiv]

In general, I think this would be good. But, I have some thoughts/comments:

1. Provide an additional option to switch on/off backing up before updating.
   Background: I will likely plan auto-updates to happen about 1 hour after my usual weekly backup. Therefore I don't want/need to backup again. However, someone who uses immediate update might want to backup first.
2. Make it possible to change the on/off status from an automation.
   Background: I avoid any restarts I can avoid while I'm not home for longer time. If anything would prevent HA to come back online, I could not have a deeper look and manually intervene. Therefore, I would prefer to automatically block auto-updates if vacation mode is on.
3. Make it possible to skip a single update (while auto-update awaits its schedule).
   Background: That way, it would be possible to skip an update for which issues are known without having to switch off auto-updates completely (e.g. specific integration I use would break).
4. Make it possible to discard the update notification while still applying the update automatically.
   Background: I might want to get notified about availability to be able to update manually. But, I don't want to have this notification the whole time the auto-update awaits its schedule.
5. Make it possible to block auto-updates to a specific release centrally.
   Background: A major regression slips through. This is recogized some time after the release. Then, it would be good to have the chance to switch off the auto-update to this release centrally instead of continuing to apply auto-updates in more instances which are not yet broken.