Tunnel and Network-Oriented Commands

8.1 bbx ng-config #

ng-config is the operator-controlled nginx surface for a BrowserBox instance that has already been configured. It reuses the saved hostname, main port, backend mode, service-host mappings, and certificate directory:

bbx ng-config print
bbx ng-config validate
bbx ng-config apply

With main port 8888 and parent domain example.com, the default output maps p8886 through p8889 to the audio, docs, main, and DevTools ports described in Section 7.6. When zeta/host-per-service configuration already exists, ng-config reuses those persisted ADDR_<port> names rather than creating a second hostname scheme.

For an external nginx host:

# BrowserBox host
bbx ng-config print > /tmp/browserbox-facade.conf

# Review and transfer through your normal configuration process.
scp /tmp/browserbox-facade.conf edge-admin@edge.example:/tmp/

The generated certificate paths come from the BrowserBox host’s saved certificate directory: BBX_SSLCERTS_DIR, or SSLCERTS_DIR. If the edge stores the certificate elsewhere, change only those two paths during operator review; the service hostname and port mappings remain authoritative.

For nginx on the BrowserBox host:

bbx ng-config validate
bbx ng-config apply

8.2 bbx ng-run #

bbx ng-run

This is the nginx-oriented workflow. It will trigger zeta-mode setup when needed, expects hosts.env support for per-service hostnames, runs nginx setup, and then starts BrowserBox.

Route domain selection. #

bbx ng-run creates per-service hostnames under a route domain. Because of that, localhost is not a valid ng-run route domain: names such as audio.localhost or devtools.localhost are not portable DNS targets and should not be relied on. localhost remains valid for the direct bbx run and bbx start workflows.

For local nginx testing, use a wildcard-safe local name such as bbx.test or ci.test:

bbx setup --hostname bbx.test --port 11111 -z
bbx ng-run

ng-run chooses its route domain in this order:

1. An explicit caller override, such as DOMAIN=example.test bbx ng-run.

2. The saved DOMAIN from the previous bbx setup.

3. The saved setup hostname, when it is suitable for generated subdomains.

Use DOMAIN only when you need to override the saved setup domain for this run:

DOMAIN=example.test bbx ng-run

If the final resolved route domain is localhost, BrowserBox refuses to continue and asks for a wildcard-safe domain instead. This protects nginx routing and certificate generation from creating unusable subdomain URLs.

8.3 bbx tor-run #

bbx tor-run [--anonymize|--clearnet-only|--no-darkweb] [--onion|--no-onion]

This mode sets up Tor integration and can expose BrowserBox through onion routing. --anonymize routes the remote browser’s own traffic through Tor; --clearnet-only (also spelled --no-darkweb) keeps browsing on the normal internet. --onion publishes BrowserBox as an onion service. At least one of anonymized browsing or the onion service must be enabled.

8.4 bbx zt-run #

bbx zt-run [--network-id <16 hex characters>]

This is the ZeroTier overlay-network entry point for private-network access. In an interactive terminal, bbx prompts for the ZeroTier network ID when --network-id is omitted. In scripts and other non-interactive use, pass --network-id; without it the command exits with ZeroTier Network ID is required.

8.5 bbx cf-run #

bbx cf-run [--port|-p <port>] [--background|-d]

This is the Cloudflare Tunnel entry point for public HTTPS exposure through Cloudflare’s edge. The tunnel’s public login link is written to ~/.config/dosaygo/bbpro/login.link as soon as Cloudflare issues it, rewritten if the tunnel address changes, and removed when the tunnel stops. Scripts can therefore read the current link from that file instead of parsing console output.