Britive Bridge v2.2.0
What’s New
Britive Bridge v2.2.0 adds clustering, makes license state visible instead of something you discover on failure, and moves tenant and license configuration out of the container image into the deployment that runs it.
Clustering
A new cluster block decides what a Bridge container is — an orchestrator, or a worker — and, for an orchestrator, what it manages: session and proxy worker limits, and the reconcile loop that provisions them.
Single-container deployments are unaffected. Every setting has a working default, so a clustered deployment sets only what differs.
License Visibility
The web interface footer now carries a license indicator, colored by how close expiry is — green above 60 days, yellow at 60 or fewer, red at 30 or fewer or once the grace period is running. The text names the state, counting down as in License: 12 days left.
In limited mode every gated feature returns 403 with a message naming the feature and telling you to install a license. Nothing fails silently. A valid license unlocks native protocol access, live session viewing and control, recording, file, and video downloads, and multiple sessions per checkout.
Upgrading
Two changes to make in the same update. Before v2.2.0 the Britive tenant, the OAuth redirect, and the license were baked into the image. They now come from the stack.
- Set
BritiveTenant. An update that takes the v2.2.0 image without it succeeds and the cluster comes up healthy — but no tenant is configured, so Login with Britive disappears from the web app. - Rename
BridgeApiUrltoBridgeUrl. The CloudFormation parameter changed name.BridgeUrlis the public browser address used for the OAuth callback, and is separate fromBRIDGE_API_URL, which the co-located broker uses to reach Bridge over loopback.