Bridge & Broker Network Architecture

This page maps every port and communication channel the Bridge and its co-located Broker use, so you can design firewall rules and a complete architecture picture before you deploy. The deployment guides cover how to run each shape; this page covers what talks to what.

The Broker is co-located with the Bridge. The Bridge web/API tier, the native protocol proxies, and the Britive Broker run together — as one process in single-role, or alongside the orchestrator in a cluster. The broker’s checkout scripts and the bridge’s session proxy therefore share the same network interface and security group: a target firewall sees one source, but it must allow every port below.

Deployment Shapes

The Bridge ships as one container image that runs in two shapes. Both use the identical network model described here — only the host and orchestration differ.

Shape	What runs	Typical use	Guide
Single-role	One process: web/API, native proxies, and the co-located broker	Trials, labs, small teams	Single-Server
Cluster	`orchestrator` + `proxy` + `session` roles that scale out; broker runs with the orchestrator	Production	AWS (ECS) · Kubernetes

Network Planes

The Bridge and broker touch four network planes: control (outbound to the Britive platform), user access (inbound), internal (datastore and shared storage), and resource egress (outbound to your targets). Every connection to the Britive platform is outbound only — the broker polls for work; nothing dials in from Britive.

    flowchart TB
  Users["Users<br/>browser 443 · native SSH / RDP / DB"]
  SaaS["Britive platform<br/>https://&lt;tenant&gt;.britive-app.com : 443"]

  subgraph Host["Bridge host — Bridge + co-located Broker"]
    Bridge["Bridge<br/>web/API + native proxies"]
    Broker["Broker<br/>runs checkout / checkin scripts"]
  end

  Deps[("PostgreSQL datastore<br/>shared recordings storage")]

  subgraph Targets["Target resources"]
    Prov["A · Broker provisions (at checkout / checkin)<br/>SSH · WinRM · LDAP · DB admin"]
    Sess["B · Bridge session proxy (live session)<br/>SSH · RDP · DB"]
  end

  Users -->|inbound| Bridge
  Broker -.->|"outbound 443 · poll work, license"| SaaS
  Bridge -.->|"outbound 443 · OAuth login, license"| SaaS
  Broker -->|"register checkout (cluster token)"| Bridge
  Bridge --> Deps
  Broker --> Prov
  Bridge --> Sess

Keep native listeners private. Some native protocols can carry credentials in clear text. Expose the web tier (443) through the load balancer, but restrict the native listeners (SSH / RDP / database ports) to your private network, VPN, or zero-trust range.

Checkout & Session Lifecycle

A just-in-time session flows across all four components. The broker provisions a temporary account on the target at checkout and removes it at checkin; the bridge proxies the live session in between.

    sequenceDiagram
  actor User
  participant SaaS as Britive platform
  participant Broker
  participant Bridge
  participant Target
  User->>SaaS: 1. Request checkout (profile)
  Broker->>SaaS: 2. Poll 443, get work
  Broker->>Target: 3. Provision temp account (SSH / WinRM / LDAP / DB admin)
  Broker->>Bridge: 4. Register checkout (cluster token)
  User->>Bridge: 5. Connect (browser 443 / native ports)
  Bridge->>Target: 6. Proxy session (SSH / RDP / DB)
  Note over Bridge: session recorded to shared storage (always on)
  Broker->>Target: 7. On expiry / checkin, remove temp account

Ports & Communication Channels

Control plane — Bridge/broker → Britive platform (outbound)

Source	Destination	Port	Purpose
Broker	`https://<tenant>.britive-app.com`	TCP 443	Poll for checkout/checkin work; fetch and refresh the license
Bridge	`https://<tenant>.britive-app.com`	TCP 443	Britive OAuth login validation; license status

Outbound only — no inbound rule from Britive is ever required. Route through HTTPS_PROXY / NO_PROXY / SSL_CERT_FILE if egress is via a forward proxy.

User-access plane — users → Bridge (inbound)

Source	Port	Backend	Purpose
User browser	TCP 443	LB → Bridge web/API	Browser sessions (all protocols), web UI, checkout picker, admin
Native SSH client	TCP 22 (often 2222)	LB → Bridge	SSH wire proxy
Native RDP client	TCP 3389	LB → Bridge	mstsc / xfreerdp
Native MySQL client	TCP 3306	LB → Bridge	`mysql` wire proxy
Native PostgreSQL client	TCP 5432	LB → Bridge	`psql` wire proxy
LB health probes	Bridge web/API port	LB → Bridge	`/readyz` (readiness), `/livez` (liveness)

Ports and TLS termination vary by platform. In single-server mode the Bridge can terminate TLS directly on 443. In a cluster behind a load balancer, the web/API tier commonly listens on 8080 and native SSH on 2222, because many container platforms restrict binding privileged ports (<1024); the load balancer then publishes 443 and 22 and terminates TLS, forwarding to the internal ports. MSSQL (1433) is enabled in the container but may not have a dedicated native listener depending on your load balancer’s listener limits — reach it through the browser SQL client in that case.

Internal plane — Bridge dependencies

Source	Destination	Port	Purpose
Broker	Bridge admin API	Bridge API port (e.g. 8080)	Register/delete checkouts (needs `BRIDGE_CLUSTER_TOKEN`, `BRIDGE_API_URL`)
Bridge	PostgreSQL	TCP 5432	Datastore — checkouts, sessions, audit, encrypted credentials (mandatory)
Bridge	Shared recordings storage	TCP 2049 (NFS)	Recordings, auto-generated TLS certs, SSH host keys (shared across cluster workers)

Resource plane — → your target resources (outbound)

Two distinct outbound paths, both from the same Bridge/broker network interface.

A. Broker → target — provisioning (runs the checkout/checkin scripts that create and remove a temporary account or grant). Only the resource types you onboard apply.

Target	Port	Protocol	Notes
Linux	TCP 22	SSH	Privileged provisioning user (default `britivebroker`)
Windows	TCP 5985 / 5986	WinRM (HTTP / HTTPS)	`WINRM_NO_SSL=1` → 5985, `0` → 5986
Windows	TCP 22	SSH	Alternative provisioning transport
Active Directory	TCP 389 / 636	LDAP / LDAPS	`ldapsearch` scans; DC changes via WinRM/SSH to a DC
MySQL	TCP 3306	MySQL	Admin connection; TLS verified by default
PostgreSQL	TCP 5432	PostgreSQL	Admin connection; TLS verified by default
MSSQL	TCP 1433	TDS	Admin connection; TLS verified by default

B. Bridge → target — live session proxy (the actual user session, after checkout).

Target	Port	Protocol
Linux	TCP 22	SSH
Windows	TCP 3389	RDP
MySQL	TCP 3306	MySQL
PostgreSQL	TCP 5432	PostgreSQL
MSSQL	TCP 1433	TDS

Firewall / security-group checklist

From the internet: 443 to the load balancer only.
From your private network (VPN/VPC): the native ports you enable (22 or 2222 / 3389 / 3306 / 5432) to the load balancer.
From the Bridge to the Britive platform: 443 outbound.
From the Bridge to PostgreSQL: 5432; to shared recordings storage: 2049.
From the Bridge to each target: the union of the provisioning (A) and session (B) ports for every onboarded type — a Linux host needs only 22; a Windows host needs 5985/5986 (provision) and 3389 (session); a database needs its admin+session port (the same number).
On each target: allow the Bridge source — security group, subnet CIDR, or host IP — on those ports.

Next Steps

Follow a full walkthrough: Single-Server, AWS (ECS Fargate), or Kubernetes.
Enable the co-located broker: Broker Integration.
Turn on the protocols you need: Protocols.
Control who provisions what: Checkouts.
Configure authentication and licensing.

Last updated on August 5, 2026