Broker Integration

Britive Bridge ships with the Britive Broker built into its container image. The broker is Britive’s lightweight agent that makes outbound connections to your tenant and lets the platform reach on-premises resources without any inbound firewall openings. Running it alongside Bridge lets the Britive platform drive Bridge - creating and revoking checkouts as users request access - over that same outbound channel.

The broker is optional. Bridge runs fully without it - you can create checkouts directly via the API. Enable the broker when you want the Britive platform to orchestrate access to the targets Bridge fronts, and to have Bridge retrieve its license automatically (see Licensing).

How it fits together

The broker binary is bundled in the Bridge image and runs as a supervised process next to the Bridge - on the orchestrator in a cluster, or in the single container in standalone mode. You deploy nothing extra.
On startup, when a broker token is present, Bridge writes the broker’s config and starts it. The broker registers with your tenant’s broker pool and opens its outbound connection.
When a user requests access in Britive, the platform routes the request to the pool; the broker calls the Bridge admin API (create the checkout), and the user then connects through Bridge as normal - recorded and time-boxed.
The same token authenticates Bridge’s automatic license fetch, so a broker-connected deployment also keeps its license current on its own.

    flowchart LR
  P["Britive platform"] <-->|"outbound, TLS"| B["Britive Broker<br/>(in the Bridge container)"]
  B -->|"Bridge admin API"| BR["Bridge"]
  U["User"] -->|"connect: SSH / RDP / …"| BR --> T[("Target")]

Enabling it

Set these on the Bridge container (the orchestrator in a cluster, or the single container in standalone mode):

Variable	Required	Description
`BRITIVE_BROKER_AUTH_TOKEN`	yes	The broker-pool authentication token from your tenant (Britive → broker pool). Turning this on activates the co-located broker and automatic license retrieval.
`BRITIVE_BROKER_TENANT_SUBDOMAIN`	yes	Your tenant subdomain (e.g. `acme` for `acme.britive-app.com`).
`BRIDGE_API_URL`	usually required	Base URL the broker uses to reach the Bridge admin API. Default `https://localhost:8080` — but the standalone deployment serves the API on 443, so set `https://localhost:443`. In a split cluster, point it at the proxy/load-balancer URL.
`BRIDGE_CLUSTER_TOKEN`	yes	Admin auth for the Bridge API - the broker’s toolbox sends it as the `X-Bridge-Cluster-Token` header to create checkouts. Required whenever the broker is enabled, standalone included (any strong secret; the Bridge and broker share the value — in a single container that’s one env var). Without it, checkouts fail with `cluster token required`.

When the token is set, Bridge renders the broker config to /opt/britive-broker/config/broker-config.yml and supervises the broker process for you - there is nothing else to install or run.

Where the token comes from

In the Britive console, create (or open) a broker pool and copy its authentication token. Treat it as a secret - provide it through your platform’s secret mechanism, never in plaintext in a committed file.

Examples

Standalone (docker-compose)

docker-compose.standalone.yaml (bridge service)

    environment:
      BRIDGE_CONFIG: /etc/britive-bridge/config.yaml
      BRIDGE_ENCRYPTION_KEY_B64: "${BRIDGE_ENCRYPTION_KEY_B64:?}"
      # Broker integration + automatic license retrieval:
      BRITIVE_BROKER_AUTH_TOKEN: "${BRITIVE_BROKER_AUTH_TOKEN:?}"
      BRITIVE_BROKER_TENANT_SUBDOMAIN: "acme"
      BRIDGE_CLUSTER_TOKEN: "${BRIDGE_CLUSTER_TOKEN:?}"   # broker's admin auth to the Bridge API
      BRIDGE_API_URL: "https://localhost:443"            # standalone serves the API on 443 (not the broker's :8080 default)

Kubernetes

Add the broker values to the bridge-secrets Secret in the Kubernetes manifest before you apply it, or patch the Secret in an existing deployment:

bridge-cluster-k8s.yaml

stringData:
  BRITIVE_BROKER_AUTH_TOKEN: "<broker-pool-token>"
  BRITIVE_BROKER_TENANT_SUBDOMAIN: "acme"
  BRIDGE_API_URL: "http://localhost:8080"

AWS ECS (CloudFormation)

The bridge-v2 stack exposes BrokerAuthToken, BrokerTenantSubdomain, and BridgeApiUrl as parameters, wired into the orchestrator task definition.

Verifying

Confirm the broker came up next to Bridge:

Logs - the Bridge container’s log stream includes the broker process; look for it registering with the pool on startup. In a cluster, this is on the orchestrator task/pod.

Bridge admin API reachability - the bundled toolbox can sanity-check the API the broker talks to:

# inside the container (orchestrator/single)
/opt/britive-broker/scripts/broker-bridge-api.sh health
/opt/britive-broker/scripts/broker-bridge-api.sh admin-validate   # verifies the cluster token

In the console - the broker pool shows the broker as connected, and access requests to the targets Bridge fronts begin to succeed.

Only one broker runs per deployment - it lives with the always-on orchestrator (or the single container). Session and proxy workers never run a broker.

Last updated on July 8, 2026