Config as code

A firewall's entire policy, upstreams, rules, and exceptions, is one JSON document. That makes it a natural fit for git: policy changes become pull requests with review and history, and applying them is one command. It is the GitOps approach applied to dependency policy. This tutorial walks the full loop once: export, commit, change, import, verify, roll back.

You need the CLI configured (BYTESAFE_ENDPOINT, BYTESAFE_NAMESPACE, BYTESAFE_TOKEN) and a firewall to work with. Replace <firewall-id> with its ID, not its name.

Step 1: export the configuration

bsfw config export --firewall <firewall-id> > firewall-config.json
git add firewall-config.json
git commit -m "Snapshot firewall config"

Open the file. You will recognize the structure from the firewall config reference: upstreams, rules, exceptions, permissions. Upstream credentials are placeholders, not secrets; the export is safe to commit.

Step 2: change policy in the file

Add a rule to the rules array, for example a 14-day delay rule:

{
  "id": "delay-14d",
  "executionPhase": "versions",
  "selector": { "maxAgeHours": 336 },
  "ruleEffect": { "block": true, "log": true },
  "description": "Block versions younger than 14 days"
}

Commit it. In a team setup this is where the pull request happens: the diff shows exactly which policy changes, and review happens like any code review.

Step 3: import it back

bsfw config import --file firewall-config.json

Import replaces the whole configuration with the file's content. The firewall's version increments, and the change lands in the audit log as firewall.config.upsert.

Because it is a full replace, anything changed in the dashboard since your export is overwritten. Once a firewall is managed from git, treat the file as the source of truth: export first if someone may have edited it elsewhere.

Step 4: verify

bsfw rules --firewall <firewall-id>

The new rule is in the list. Requests now evaluate against it; a package version younger than 14 days is filtered.

Step 5: roll back

Every import creates a new config version, and the server keeps history. To roll back, re-import the previous file from git:

git checkout HEAD~1 -- firewall-config.json
bsfw config import --file firewall-config.json

The API can also roll back server-side to a recorded version (PUT /v1/<namespace-id>/config/<firewall-id>/version/{version}, history via GET .../history), which is useful when the git copy is not at hand. See the API reference. Either way, a rollback is itself a new version; history moves forward.

What does not travel through git

Credentials. Exports carry placeholders instead of secret values, and imports reject plaintext secrets, so a config file cannot leak an upstream credential. The flip side is that credentials do not travel with the config: after importing a firewall into a new environment, set them once with the CLI.

bsfw config credentials --firewall <firewall-id> --upstream <upstream-id>

See Manage upstream credentials.

Next steps

• Make this a pipeline: Manage config as code covers repo layout, CI import, and drift detection.
• Run the import from CI without stored secrets: GitHub Actions.
• Reference: Firewall config, CLI.