Why we recommend FQDN-based allowlisting

When configuring firewall rules for Workbrew, we recommend allowlisting by fully qualified domain name (FQDN) rather than by IP address. This page explains why, and covers the network architecture behind the recommendation.

Console IP addresses are not static#

console.workbrew.com resolves to anycast IP addresses managed by our hosting provider's CDN layer, not by Workbrew directly.

While these IPs tend to remain stable for extended periods, there is no guarantee they will stay the same. They can change due to infrastructure rebalancing, DDoS mitigation, or platform updates, all without advance notice.

If your firewall only supports IP-based rules, you would need to allowlist the CDN provider's entire published IP ranges, which is a very broad set and defeats the purpose of scoping access.

Cask downloads come from vendor servers#

Unlike bottles (which are centrally hosted on ghcr.io), cask artifacts are downloaded directly from each application vendor's own servers. This means the set of destination IPs depends entirely on which casks your fleet installs and where each vendor hosts their downloads.

There is no fixed list of IPs that covers all possible cask downloads. FQDN-based rules let you allowlist specific vendor domains as needed without tracking their underlying IPs.

Proxy auto-detection as an alternative#

For organizations that cannot do FQDN-based filtering, the Workbrew Agent supports HTTP proxies. On macOS, it automatically detects system proxy settings, including PAC (Proxy Auto-Configuration) files. Routing Workbrew traffic through a proxy allows centralized control without maintaining individual firewall rules for each domain.

See Configure your firewall for Workbrew for setup instructions.