BytesafeDependency Firewall

Deployment models

The two ways to run the Bytesafe Dependency Firewall, SaaS or self-hosted on your own infrastructure, and what changes between them.

The Dependency Firewall is the same product in every deployment model: the same rules, ecosystems, CLI, and API. What changes is where the proxy runs and who operates it.

SaaS

The default. Bytesafe operates the service; you create a namespace, point package managers at your endpoint, and everything in these docs applies as written. Package traffic flows through Bytesafe-operated infrastructure, with upstream credentials encrypted at rest.

Choose SaaS unless a policy says you cannot: it is the shortest path to a working firewall and carries no operational load.

Your own infrastructure (self-hosted)

For organizations whose packages, credentials, or network topology must not leave their environment, the firewall runs on your own infrastructure, self-hosted in your datacenter or your cloud account. You operate it; package traffic and upstream credentials never leave your perimeter. Internal registries that are unreachable from the internet can then sit behind the firewall as upstreams, which SaaS cannot reach.

The self-hosted page summarizes availability. Contact support@bytesafe.dev to discuss deployment requirements and setup.

What does not change

  • Client configuration. Package managers speak the same protocols against the same URL shapes; only the hostname differs. Ecosystem pages apply unchanged.
  • Policy and API. Rules, exceptions, tokens, the management API, and bsfw work identically, which also means config as code can move a firewall between deployment models: export from one, import into the other, set credentials.

What to check for self-hosted

Two capabilities depend on services around the core proxy, so confirm them for your environment when planning a self-hosted deployment: vulnerability data for the vulnerabilities selector, and malware scanning for the malware selector.

On this page