Go

A Go firewall implements the GOPROXY protocol (list, latest, info, mod, zip). The standard Go toolchain downloads modules through it; no extra client is involved.

The examples use <namespace-id> and <firewall-id> placeholders. Replace them with IDs, not with namespace or firewall names. The firewall's Setup tab shows these snippets with both values already filled in.

Proxy endpoint

https://eu-sov-1.bytesafecloud.eu/v1/<namespace-id>/go/<firewall-id>

The namespace ID and firewall ID are part of the URL. Authentication is HTTP basic auth with the access token as the password; the username can be anything.

Configure the toolchain

Set GOPROXY with the credentials embedded:

export BYTESAFE_TOKEN=<your token>
export GOPROXY="https://go:${BYTESAFE_TOKEN}@eu-sov-1.bytesafecloud.eu/v1/<namespace-id>/go/<firewall-id>"

Do not append ,direct or another proxy as a fallback. Go falls back to the next GOPROXY entry on errors, which would turn every firewall block into a silent bypass.

go env -w GOPROXY=... persists the setting per machine, but it writes the token to the Go env file in plain text. Prefer the environment variable so the token stays in your shell or CI secret store.

The checksum database

The Go toolchain verifies downloaded modules against the public checksum database (sum.golang.org). Modules served through the firewall are byte-identical to upstream, so public modules verify as usual. Modules from an internal upstream are not in the public database and fail verification; exempt them:

export GONOSUMDB="go.acme.internal/*"

Use GONOSUMDB, not GOPRIVATE: GOPRIVATE also excludes the modules from GOPROXY, which would fetch them directly from version control and bypass the firewall.

Verify

go mod download golang.org/x/text

With no fallback in GOPROXY, a successful download confirms the firewall served the module.

Do not expect a log entry from this. A request is logged only when it matches a rule with log: true or a logging exception, so a download that breaks no rule leaves no trace. An empty log is not evidence that the toolchain bypassed the firewall. To see the requests while verifying setup, add a log-only rule that matches all modules. See What is logged when.

CI

Use a Service Access Token (SAT) instead of a PAT. Set it as a secret in your CI system and build GOPROXY from it before build steps.

To correlate all requests from one pipeline run, append an interaction ID to the token:

export GOPROXY="https://go:${BYTESAFE_TOKEN}::${CI_PIPELINE_ID}@eu-sov-1.bytesafecloud.eu/v1/<namespace-id>/go/<firewall-id>"

The ID shows up on each log entry generated by a matching logging rule or exception from that run.

Publishing

There is nothing to publish to a Go firewall. Go modules are distributed from version control, not uploaded to registries, so the firewall's upload phase does not apply to the Go ecosystem.

What a blocked download looks like

Rules on the versions phase filter versions out of the proxy's version list. The effect depends on how the module is requested:

• go get module@latest and queries like @v1 resolve to the newest version that passed the rules.
• A go.mod requirement on an exact filtered version fails as not found, since modules are pinned by exact version in go.mod.

Rules on the download phase block the module fetch. The firewall returns a 404 with:

golang.org/x/text@v0.3.7 is blocked. Check firewall log entries for request <request-id> for details

Take the request ID to the logs to see which rule fired. See Investigate a blocked install.

Troubleshooting