You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pick a category — ↑↓ to move, ENTER to choose, ESC to quit.
Pick packages — type to search, ENTER takes the highlighted row, TAB ticks several, ctrl+a takes all. Each row shows whether it is already installed. The last row goes back to the categories.
Choose the operation — Install, Reinstall, Uninstall, or Open official page. Only the ones that make sense for your selection are offered, and all of them act on the same selection from the same page.
Homebrew output streams live in a fixed-height window while it works. Nothing is written to disk.
Useful flags: --list prints the catalogue, --dry-run previews without changing anything, --quiet swaps live output for spinners, and --all with --category NAME (plus --uninstall / --reinstall) runs non-interactively. --help has the rest.
How to Read the Catalogue
Every row lists the exact argument you pass to Homebrew.
Marker
Meaning
Example
token
In homebrew/cask or homebrew/core — install directly
The docker compose plugin — define and run multi-container environments
ℹ️ docker and docker-compose are separate formulae — docker alone has no compose subcommand.
After installing docker-compose, point Docker at Homebrew's plugin directory or docker compose won't be found. Add this to ~/.docker/config.json:
Colima and container are self-contained — brew install colima pulls in Lima as a dependency, so there's no need to install it separately.
With colima start running, docker and docker compose work unchanged against it — no GUI app needed anywhere.
Apple's container and podman each speak their own CLI rather than the Docker socket, so on their own they do not back the docker command. Socktainer closes that gap for container: it serves a Docker-compatible REST API, so pointing DOCKER_HOST at it makes docker and docker compose work against Apple's runtime.
⚠️ Socktainer pins the Apple container version it was built against. socktainer 1.2.1 requires container 1.2.0 and refuses to start against 1.3.0; upstream warns that bypassing the check with --no-check-compatibility causes XPC errors. If the service fails, read $(brew --prefix)/var/log/socktainer.log — it names the exact version mismatch.
The socket path depends on how socktainer is launched: under brew services it binds $HOMEBREW_PREFIX/var/run/socktainer/.socktainer/container.sock (the path in Homebrew's caveat); run by hand it binds .socktainer/container.sock relative to the current directory. lsof -p $(pgrep -f socktainer) shows which one is live.
Do not run brew services start container — the Apple runtime registers its own launchd agents through container system start, and the Homebrew service collides with them (Bootstrap failed: 5).
Docker Desktop's cask already installs its own docker and docker-compose binaries, so these formulae are redundant — and a second copy on PATH can shadow it. OrbStack ships orb/orbctl and provides the docker CLI from its own bin directory rather than through Homebrew.
Not macOS apps and not on Homebrew — these run in a browser or as a service you host yourself. Listed here so the catalogue stays honest about what brew can and cannot install.
Port Killer is the only app here that lives outside homebrew/cask. Passing the full owner/tap/token path taps automatically, so no separate brew tap is needed.
brew install --cask productdevbook/tap/portkiller
Use the interactive install script to pick only what you need — no bloat, no surprises.