What on-premises browser isolation actually means
RBI runs the browser away from the user's device; when you self-host it on your own Kubernetes, that "away" is inside your datacenter - not a vendor's cloud - so isolation and data residency are enforced together.
Your infrastructure, your boundary
The remote browser, the app it loads, and the session data all stay inside your perimeter.
Runs on the Kubernetes you have
Browser pods deploy into your existing cluster and follow the policies and monitoring your team already runs.
Full isolation, on your terms
Malware and data-leak protection, with direct control over egress, retention, and session recording.
Why run RBI on-prem & hybrid
It runs on the Kubernetes you already picked, sits close to your apps, and only reaches the cloud when you want it to.
Works with your Kubernetes
OpenShift, Rancher/RKE2, k3s, Tanzu or plain K8s. Same CNI, storage and identity you use today.
Faster because it's local
The browser runs next to your internal apps, so pages load without the extra trip out and back.
Cloud only when you need it
Keep sensitive work on-prem. Send peak load to the cloud when you choose.
On-prem & air-gapped deployment - end to end
Nothing depends on an external RBI cloud - a fully disconnected deployment is supported.
Stand up your Kubernetes cluster on your hardware/private cloud - reuse your CNI, storage and IdP.
Create the Thinfinity isolated-browser image into your private registry - pods pull locally, no internet.
Deploy the broker & gateway in-cluster (or DMZ); browser pods reverse-connect outbound - no inbound ports.
Deliver intranet & SaaS apps through a POD-hosted browser streamed to the endpoint via the Thinfinity Gateway; bind SSO/SAML/OAuth, MFA, and RBAC
User is brokered to a fresh pod that loads the app; only encoded pixels return; pod destroyed at logout.
Thinfinity RBI Main Features
Isolated browser sessions running in Kubernetes pods, delivered through the Web Application Gateway.
| Feature | What it does | Policy control |
|---|---|---|
| Isolated browser session | The browser runs in a container pod in your cluster, never on the endpoint; only the rendered session reaches the user | Per user or group |
| Ephemeral sessions | The pod is created at session start and destroyed at logoff, leaving no residual state between users | On by default |
| Clipboard redirection | Copy and paste between the endpoint and the isolated browser | Off / in / out / bidirectional |
| File transfer | Upload to and download from the isolated session | Off / download / upload / both |
| Audio redirection | Audio from the remote browser played on the user endpoint | Enable / disable per resource |
| Printing | Print from the isolated session to the user's local printer | Enable / disable per resource |
| Authentication at the gateway | SSO via SAML, OAuth/OIDC and directory sources, with MFA | Per application |
| RBAC | Which users and groups can open which published browser resources | Per user or group |
| Session recording | Recording of the isolated browser session for audit | Enable / disable per resource |
| Access hours | Restricts when a resource can be opened, by day and hour | Per user or group |
| Monitoring | Gateway, broker and pod-level metrics for capacity and performance | Platform-wide |
No inbound ports - nothing reaches the endpoint
In air-gapped mode, no outbound internet either: pods reverse-connect internally, only an encoded pixel stream crosses the wire, and clipboard/download/print stay off until policy allows.
Isolated browser pod
On your on-prem / hybrid cluster - loads the app from your private registry. Data stays here.
Thinfinity gateway
Pods reverse-connect outbound. No inbound ports, no exposed apps. SSO / MFA / RBAC.
User's browser
Any device. Receives only an encoded pixel stream - nothing else reaches the endpoint.
Zero Trust by design: users are brokered to a single isolated session, never to the network.
Isolated access to internal web apps & SaaS
Give BYOD users, contractors and third parties isolated access to sensitive internal web apps and privileged consoles without those apps being reachable from outside your datacenter.
BYOD / unmanaged devices
Internal apps from personal devices - no agent, no MDM; data off the device.
Third-party & contractor access
Onboard outsiders in minutes to specific apps; revoke instantly - no VPN, no standing access.
Privileged web consoles
Admin UIs, Kubernetes & DB consoles - credentials and data never land on the endpoint.
Sensitive internal portals
HR, finance, clinical or case systems that must never be reachable from the open internet.
Beyond day-to-day internal access
Regulated & fully air-gapped
App & data stay in your datacenter - disconnected where mandated; data-residency rules met.
Offshore / outsourced / BPO
CRM & internal apps for low-trust agents with watermarking & anti-screen-scrape controls.
M&A & seasonal workforce
Grant thousands temporary isolated access fast, then revoke - no VDI/VPN to provision.
Replace VPN/VDI for web users
Right-size: isolated browser for the many, full VDI only where truly needed.
Outbound risky-web isolation
Bonus: the same on-prem fleet isolates risky sites & email links - phishing, malvertising, zero-days.
Data stays in your boundary - and it's not browser-only
Because the browser runs in a pod in your datacenter, isolated content stays within your security boundary - and the same self-hosted platform brokers more than the web.
Data stays in the pod
Only an encoded stream reaches the endpoint; page, cookies and tokens never land locally.
Granular, identity-based DLP
Toggle clipboard, upload/download and print per profile; watermarking and session recording for sensitive apps.
Multi-protocol, one platform
Isolated web/SaaS plus RDP, VNC, SSH and full VDI - one on-prem deployment covers web and legacy systems.
On-prem & air-gapped RBI FAQs
Yes - mirror the browser image to your private registry; no outbound internet, sessions brokered internally, only pixels cross the wire.





































