Network requirements

Workbrew traffic runs in two directions. Devices make outbound connections to the Workbrew Console and to package sources. The Workbrew Console makes outbound connections to services you control, such as a Git host or an MDM, once you connect an integration to it. Most of this page covers the first direction. IP addresses covers both.

Workbrew devices need outbound HTTPS access (port 443) to a set of domains for agent communication, Homebrew metadata, and package downloads.

Required domains#

All communication uses HTTPS on port 443.

Downloads that span two hostnames#

cdn.workbrew.com serves small files itself and redirects binary downloads to the object storage hostname above. Allowing cdn.workbrew.com on its own is not enough, because the redirect target is where the installer, disk image, or update feed is fetched from. Filters that allow or block by content category often classify the storage hostname under its cloud provider rather than under Workbrew, so it can be blocked while cdn.workbrew.com is allowed.

Agent automatic updates try cdn.workbrew.com first and fall back to console.workbrew.com when that fails, so updates continue if the storage hostname is blocked. The Workbrew app, currently in early access, has no such fallback. Both its download and its update feed require the storage hostname.

Cask download domains#

Cask downloads are fetched directly from each application vendor's servers. These vary by cask and cannot be predicted as a fixed list. For example:

• dl.google.com for Google Chrome
• download.mozilla.org for Firefox
• github.com or *.githubusercontent.com for GitHub-hosted releases

If your firewall restricts outbound traffic, you will need to allowlist vendor domains on a per-cask basis depending on which casks your fleet uses. See Configure your firewall for Workbrew for step-by-step setup instructions.

IP addresses#

Which addresses matter depends on the direction of the traffic.

Devices connecting to the Console#

We recommend allowlisting by FQDN (for example console.workbrew.com) rather than by IP address. The IPs behind console.workbrew.com are Cloudflare anycast addresses managed by our hosting provider and can change without notice. See Why we recommend FQDN-based allowlisting for details.

The Console connecting to your services#

Some integrations point the Workbrew Console at a host you control. The Console then makes outbound requests to that host, so a network that only accepts traffic from known sources has to allow the Console's outbound addresses.

The Console sends these requests from two fixed IP addresses:

• 67.207.88.80
• 167.99.156.159

Every request is HTTPS on port 443. The Console does not use SSH, so port 22 is not required for any integration. The Console does not clone Git repositories either. It reads them through the host's REST API.

These are the integrations that connect to a host you supply:

An allowlist is most often needed for a GitHub organization that has IP allow listing turned on, for a self-hosted GitLab instance, or for an MDM that is only reachable from inside your network. In all of these cases the integration fails until the two addresses above are allowed.

No integration requires an inbound connection from your host to the Console. The Console polls, so you do not need to open anything towards us.

Devices reach private Taps directly rather than through the Console, so a Git host that serves private Taps must be reachable from your fleet as well as from the Console. See Sync and authenticate private Taps with Workbrew.

Homebrew environment variables#

Homebrew supports environment variables to redirect traffic through internal mirrors or proxies: