Overview
This page explains what the Bridge is, the vocabulary used throughout these guides, and how the system is put together. You don’t need to read the source code or be a Linux expert - everything here is in plain language.
The Big Picture
Normally, a user who needs to administer a server or database has a username and password (or an SSH key) for that system, and they keep it. That standing access is risky: credentials leak, people keep access after they change roles, and it’s hard to know who did what.
The Bridge changes the model. Instead of connecting directly to the target system, the user connects to the Bridge. The Bridge:
- Checks that the user is allowed to reach that target right now (this is the checkout).
- Opens the real connection to the target on the user’s behalf, using credentials the user never sees.
- Records everything that happens.
- Tears the connection down when the checkout expires.
flowchart LR
User["User"]
Bridge["Britive Bridge"]
Target["Target system<br/>(server, database, cluster, device)"]
Recording["Recording<br/>(saved for playback & audit)"]
User -->|"connects"| Bridge
Bridge -->|"opens real connection"| Target
Bridge -->|"streams session"| Recording
Key Concepts
These terms appear constantly in the rest of the documentation. Skim them once and refer back as needed.
| Term | What it means |
|---|---|
| Checkout | A time-boxed grant of access to one target. It carries the credentials the Bridge uses to reach the target. When it expires, the session ends. |
| Session | A single live connection through the Bridge (one SSH login, one database connection, one remote desktop). A checkout can allow one or more sessions. |
| Target | The system the user ultimately wants to reach - a server, a database, a Kubernetes pod, a router. |
| Protocol | The “language” of the connection: SSH, RDP, MySQL, and so on. Each protocol is configured and enabled separately. |
| Native mode | Connecting with the normal client tool on your computer (the ssh command, the mysql CLI, Microsoft Remote Desktop) pointed at a port the Bridge listens on. |
| Browser mode | Doing the whole session inside the web app - a terminal, desktop, or query screen rendered in your browser, with nothing to install. |
| Recording | The saved capture of a session, available for playback in the web UI and for download (when licensed). |
| Admin console | An in-app screen (admin role only) showing deployment health, usage statistics, the license, and the effective configuration. |
Native vs. Browser Mode
Almost every protocol can be offered in native mode, browser mode, or both at once. They serve different audiences:
- Native mode suits power users who prefer their own tools. The Bridge opens
a network port (for example, port
22for SSH). The user points their normal client at that port, and the Bridge transparently relays the connection to the target while recording it. - Browser mode suits anyone, anywhere, with no setup. The user logs into the Bridge web app and gets a terminal, desktop, or database screen right in the page. Nothing is installed on their machine, which is ideal for contractors and locked-down laptops.
Every protocol is off by default. You turn on exactly the ones you need, in the mode(s) you want. See the Protocol Reference for the full list and all options.
What Gets Recorded
Recording is always on (a checkout can opt a specific session out). What’s captured depends on the protocol:
- Shell sessions (SSH, Telnet, Kubernetes exec) capture the full terminal, plus a structured log of the commands that were run.
- Desktop sessions (RDP, VNC) capture the screen for video playback.
- Database sessions capture every query.
- Web traffic (the HTTP proxy) captures requests and responses.
Secrets - passwords typed at a prompt, tokens in headers, credentials in request bodies - are automatically masked before anything is written to disk. See Recording & Redaction for details.
How the Bridge Is Built
The Bridge ships as a single container image. The same image can run in three different shapes, which is what the deployment guides cover:
- Single mode - one container does everything. Perfect for a proof of concept, a small team, or a lab.
- Cluster mode - the work is split across specialized containers (called roles) so the system can scale and stay available. This is what you run in production on AWS or Kubernetes.
In every shape, the Bridge stores its state in a PostgreSQL database, which is required. PostgreSQL holds checkouts, session records, and (in cluster mode) the list of running workers.
Cluster Roles (Production)
When you run in cluster mode, each container is told its role through a
setting called BRIDGE_ROLE:
| Role | Job |
|---|---|
| orchestrator | The brain. Runs database migrations on startup, elects a leader, and keeps the right number of workers running. There is always one in charge. |
| proxy | The front door. Accepts incoming connections, serves the web app, and routes each connection to a session worker. |
| session | The workhorse. Actually terminates the protocol, talks to the target, and writes the recording. These are short-lived and replaced continuously. |
You don’t manage these by hand - the orchestrator spawns and replaces them for you. The AWS and Kubernetes guides explain how this works on each platform, and the Operations guide covers running it day to day.
Licensing Overview
The Bridge runs with a Britive-issued license that is tied to your tenant. With a valid license you get everything: native protocols, live session viewing, recording downloads, and multiple sessions per checkout.
Without a license (or with an expired one), the Bridge keeps working in a limited mode - browser-only sessions for a core set of protocols, no live viewing or downloads - so you’re never fully locked out. See Licensing for the complete picture.