Operations
Once Bridge is running, the work shifts from setup to day-2 operations: keeping it healthy, applying upgrades, backing up your data, and managing licenses and secrets. This page covers the practical tasks an administrator performs over the life of a deployment.
The Admin console
Bridge includes a built-in Admin console for running a deployment without touching the command line. It is restricted to users with the admin role - regular users never see it.
You open it from the floating Admin button in the web interface. It appears as a tabbed window (modal) laid over the app, with three tabs:
Overview tab
A live picture of your deployment:
- Deployment topology - the running mode and version, plus the active proxy and session workers.
- Live session tasks - the sessions currently in flight, including how long each has been running.
- Usage statistics - activity broken down by protocol, and how much storage recordings are using.
License tab
Manage licensing without restarting Bridge. From here you can install, activate, and remove licenses. This is the recommended way to apply a renewal or upgrade. (For how licensing behaves, see Configuration → Licensing.)
View Configuration tab
A read-only view of the effective configuration - the settings Bridge is actually running with after all layers (defaults, file, environment variables) have been merged. Secrets are omitted from this view, so it is safe to look at and share for troubleshooting. Use it to confirm what Bridge is really using without hunting through files and environment variables.
Monitoring health
Bridge exposes two HTTP health endpoints:
| Endpoint | Meaning |
|---|---|
/livez | Liveness - the process is alive. If this fails, the instance is stuck and should be restarted. |
/readyz | Readiness - the instance is ready to accept new sessions. If this fails, traffic should be steered away until it recovers. |
In a clustered deployment you don’t wire these up. The orchestrator registers and deregisters workers with the load balancer for you based on their readiness - on AWS it manages the Network Load Balancer’s target health checks, and on Kubernetes the pod readiness probes and Service do the same. You don’t point anything at these endpoints; the cluster self-manages routing.
When would you use them directly? Only in a single-server deployment where you put your own reverse proxy or load balancer in front of Bridge - there, point its health check at /readyz and your uptime monitor at /livez.
For overall cluster status - which workers exist, their roles, and whether a leader is active - use the Admin console’s Overview tab, which surfaces the orchestrator’s view visually.
Network Egress
Bridge makes outbound calls to the Britive platform in two cases: retrieving and renewing its license (broker-connected deployments), and, when Britive login is enabled, completing the OAuth sign-in flow. If your environment routes internet traffic through a forward proxy, point Bridge at it with the standard environment variables:
| Variable | Purpose |
|---|---|
HTTPS_PROXY / https_proxy | Proxy for outbound HTTPS (what Bridge uses to reach the platform). |
HTTP_PROXY / http_proxy | Proxy for outbound HTTP. |
NO_PROXY / no_proxy | Comma-separated hosts/domains to reach directly, bypassing the proxy. |
Set these on the Bridge container (and, in a cluster, wherever the orchestrator runs). They must be present at startup.
These apply to Bridge’s own calls to Britive - not to the connections it brokers. This includes the co-located broker, which reaches the platform through these same standard variables (no broker-specific proxy settings are needed). Sessions to your target systems (SSH, RDP, databases, and so on) and the HTTP proxy feature’s own upstream requests always connect directly, never through this forward proxy. That is intentional: brokered access to your internal targets should not be re-routed through an internet egress proxy.
Behind a TLS-inspecting proxy
If your forward proxy terminates and re-signs TLS (a “MITM” / inspection proxy), Bridge must trust the proxy’s signing CA or its calls to the platform will fail certificate validation. Bridge - and the co-located broker - use the operating system’s trust store and honor the standard OpenSSL variables:
| Variable | Purpose |
|---|---|
SSL_CERT_FILE | Path to a single PEM bundle of trusted CA certificates. |
SSL_CERT_DIR | Colon-separated directories of trusted CA certificates. |
SSL_CERT_FILE replaces the default trust bundle - it does not add to it. If you
point it at only your inspection CA, Bridge will trust that CA alone and reject
everything else. Give it a bundle that contains both the public root CAs and
your inspection CA, or instead add your CA to the container’s OS trust store (bake
/usr/local/share/ca-certificates/<your-ca>.crt into a derived image and run
update-ca-certificates at build time - the runtime user is non-root).
Backend TLS is handled separately: to trust a target’s own CA (for example a
private database certificate) use the checkout’s target_ca_cert, not these
variables - see the Payload reference.
Upgrading
You upgrade Bridge by deploying a new container image. How the change rolls out depends on your deployment mode:
- Clustered mode. Push the new image, and the orchestrator handles the rollout for you. It cycles the proxies onto the new image and replaces idle session workers with new ones running the new image. Because it waits for workers to become idle, active sessions are not interrupted - they finish on the old workers, which are retired afterward.
- Single-container mode. There is no orchestrator to manage the change, so you simply restart the container on the new image. Plan this for a maintenance window, since restarting ends any sessions in progress.
Always upgrade in a way that lets you roll back. Keep the previous image tag available so you can revert quickly if needed, and confirm a healthy database backup exists before a major upgrade (see below).
Backups
Two things hold your durable data, and each is backed up differently:
- PostgreSQL is the source of truth. Checkouts, sessions, audit records, and encrypted credentials all live in the database. Back up PostgreSQL regularly using your normal database backup process (for example scheduled dumps or snapshots). If you can restore the database, you can restore Bridge’s state.
- Recordings live on the recordings volume. Session recordings are files in the directory set by
server.recording.output_dir. Back up (or snapshot) that volume to retain your recording history. In a cluster this is the shared volume all workers write to.
A complete restore therefore needs both the database backup and the recordings volume.
Rotating secrets
Periodically rotating secrets - database passwords, the LDAP bind password, and so on - is good practice. Most can be rotated by updating the corresponding environment variable (or config value) and restarting Bridge.
BRIDGE_ENCRYPTION_KEY_B64 is the exception - it cannot be rotated by itself. This key encrypts checkout credentials stored in the database. If you change it, Bridge can no longer decrypt data written under the old key. Rotating it safely requires re-encrypting all existing checkout data with the new key as part of the change; you cannot simply swap the value and restart. Treat this key as long-lived, store it securely, and do not change it without a planned migration.