Homebrew Autoupdate scheduling and package update control

What Homebrew Autoupdate changes in a Homebrew workflow

Homebrew Autoupdate is intended for macOS users who routinely run Homebrew but do not want to remember its maintenance commands. Its default job runs `brew update` in the background every 24 hours until the user stops or deletes the schedule. That default is narrower than a full package upgrade because formula and cask upgrades are optional flags rather than automatic consequences of installation.

The plugin can add two other operations to the scheduled run. `--upgrade` updates installed formulae and casks, while `--cleanup` clears Homebrew's cache and logs after a successful run. The project also supports narrower upgrade policies: `--only=wget,node,firefox` limits upgrades to named packages, and `--leaves-only` limits formula upgrades to top-level formulae. These flags form a concrete policy choice rather than a single all-or-nothing update setting.

It is aimed at people who accept recurring package maintenance on a personal Mac and understand that package updates can have effects outside the Homebrew command itself. Cask updates are particularly relevant because the README directs users to macOS App Management permissions when they need upgraded cask applications to remain updated in place.

The launchd scheduler behind brew autoupdate

The project uses `launchd` as its scheduling and persistence layer. A duration such as `12h` creates a relative interval measured from when the command is run. A 24-hour clock value such as `00:00` instead uses `launchd`'s `StartCalendarInterval`, so the run is associated with a specific wall-clock time every day. The README makes the difference explicit: a duration can drift across repeated runs, while a clock time remains aligned with its intended schedule.

The default command, `brew autoupdate start`, schedules `brew update` every 24 hours. Optional flags expand that job rather than replacing the core update step. `--immediate` adds an immediate run and runs when the launch agent is loaded, which the README also describes as running on system boot in its example. `--ac-only` skips execution while the Mac is on battery power.

Stopping and deleting are separate operations. `stop` retains the launch agent, its configuration, and logs, while `delete` removes those items. `status` reports whether autoupdating is running and describes the installed configuration. This separation is useful when a user wants to pause a schedule without discarding its settings or diagnostic history.

Installing the tap with command-scoped Homebrew trust

Homebrew Autoupdate is distributed as a Homebrew tap containing an external command rather than as a documented application download. The README requires trusting that command explicitly because Homebrew is moving toward requiring trust before loading commands from non-official taps. The recommended scope is deliberately narrow.

Run these commands in order:

brew tap domt4/autoupdate
brew trust --command domt4/autoupdate/autoupdate

The first command adds the tap. The second grants trust specifically to `brew autoupdate`; according to the README, it does not trust every current or future formula, cask, or command in `domt4/autoupdate`. Existing users encountering an untrusted tap warning can run the same trust command.

There is an important operational boundary. The README says an already installed launch agent continues running its scheduled built-in `brew update`, `upgrade`, and `cleanup` commands after trust enforcement is enabled. Commands used to manage that schedule, including `status`, `stop`, and `delete`, remain unavailable until the external command is trusted. Trust therefore affects management access as well as fresh command loading, and a reviewer should account for this before changing tap policy.

Starting a daily update with upgrade and cleanup

The default installation leaves upgrade and cleanup disabled, so the first practical decision is which policy to schedule. The README gives this command as its main example:

brew autoupdate start 12h --upgrade --cleanup --immediate --sudo

This requests formula and cask upgrades every 12 hours, an immediate run when the agent is loaded, and a GUI password prompt if an upgrade requires `sudo`. Cleanup runs after a successful Homebrew operation, according to the flag description. Casks with their own auto-update behavior are excluded unless `--greedy` is supplied.

For a fixed midnight schedule, use:

brew autoupdate start 00:00 --upgrade --cleanup

The `00:00` value selects `launchd`'s calendar scheduling mechanism instead of a 12-hour relative interval. After starting any configuration, the relevant management command is:

brew autoupdate status

The documentation says this displays whether autoupdate is running and describes the installed configuration. The repository has no GitHub releases, so the README and embedded command help are the available sources for supported commands and options.

Limiting upgrades to selected formulae and casks

A blanket `--upgrade` policy is not necessary. Homebrew Autoupdate documents a package allowlist that accepts both formulae and casks, including tap-qualified cask names and versioned formulae. The first real package-filtered configuration is:

brew autoupdate start 12h --upgrade --only=wget,node,firefox

Only `wget`, `node`, and `firefox` are selected for automatic upgrade under this policy. Names such as `homebrew/cask/firefox` and `node@20` are also supported by the documented examples. Packages outside the list remain untouched by this upgrade operation.

The list is not a reversible modifier. The README says it cannot be combined with `--leaves-only`. To change the selected packages, the user must delete the current setup and start again with a new list:

brew autoupdate delete

That workflow creates cleanup work beyond changing one option. The command removes the launch agent, configuration, and logs, so a user who values existing run history should inspect `status` or `logs` before deleting it. The documentation does not describe a direct `start` replacement operation for an existing allowlist.

Notifications, permissions, logs, and upgrade trade-offs

Notifications are enabled by default and use a code-signed, universal macOS app. Users who want to see only failures can pass `--notify-on-error`; `--no-notify` disables notifications. This gives three distinct policies in the documented interface: report successful and failed runs, report failures only, or suppress notifications.

Logs are separate from notifications. The command help documents `brew autoupdate logs --lines=50` for a bounded view and `brew autoupdate logs --follow` for continuous output:

brew autoupdate logs --lines=50

The README also identifies a macOS permission requirement. To keep auto-updated cask applications updated in place, including their Dock placement, the documented executable path must be allowed under System Settings / Privacy and Security / App Management. The README additionally says to allow Ruby and Terminal.app. This requirement means the scheduled process is not fully separated from macOS authorization controls.

The main limitation is policy ownership. A background scheduler can continue built-in Homebrew actions even when the external management command is not trusted. Package selection, cleanup, password prompts, notification behavior, and cask handling therefore require deliberate configuration rather than treating `start` as a universal maintenance preset.

Homebrew Autoupdate compared with manual Homebrew maintenance

The direct alternative is running Homebrew's maintenance commands yourself. The README names `brew update`, `brew upgrade`, and `brew cleanup` as the built-in operations that the launch agent can schedule. Manual use keeps scheduling and execution under the user's immediate control, with no persistent autoupdate launch agent, tap trust, configuration file, or retained autoupdate logs described by this project.

Homebrew Autoupdate changes that model in two ways. First, it persists a `launchd` schedule and can continue checking Homebrew periodically after the initiating command finishes. Second, it adds policy controls around the scheduled work, including optional upgrades, cleanup after success, selected packages, top-level formulae, immediate execution, battery exclusion, GUI authorization, and notification filtering.

The trade-off is therefore convenience against inspectability and control. Manual commands require the user to remember when maintenance should occur. Autoupdate removes that timing burden but creates a background execution path whose exact interval, package scope, trust state, permissions, and retained history must be understood. For unattended updates, Homebrew Autoupdate offers the more specific mechanism. For occasional manual maintenance, the built-in commands are the simpler choice.

Editorial conclusion

Adopt Homebrew Autoupdate if you want recurring Homebrew maintenance on macOS and understand that upgrades may change formula and cask versions in the background. Do not adopt it if unattended package changes, cask authorization prompts, or management that depends on a separately trusted third-party tap are unacceptable. Before starting, verify the intended interval and flags, then inspect `brew autoupdate status`; for a fixed daily schedule, confirm that `brew autoupdate start 00:00 --upgrade --cleanup` establishes the expected `launchd` configuration.

Frequently asked questions

Official sources

1. DomT4/homebrew-autoupdate on GitHub
2. Issues
3. License: BSD-2-Clause
4. README