Platform · Browser Terminal
A full terminal, in your browser.
A full command-line terminal over a secure, JWT-authenticated WebSocket. Run anything you'd run locally, with no local setup, no VPN, and no context-switching.
- Full command line over a secure WebSocket
- JWT-authenticated, every command audit-logged
- No local tooling, no VPN, no fuss
Overview
Why teams reach for the Browser Terminal
The jump host is where operational security quietly rots. Someone stands up a bastion, hands out kubeconfigs, and punches VPN holes; six months later nobody can say who can reach which cluster or what they ran there. The Browser Terminal collapses that apparatus into a browser tab. Click any environment from the dashboard and you have a the real command-line shell in under a second, scoped to exactly what your role permits: no local binary, no context to switch, no credential to leak off a laptop.
Every session is a signed, short-lived JWT that opens a TLS WebSocket to a per-session server-side shell. The shell process runs inside Kubentic's control plane, not on your machine, so it inherits the cluster's in-region API endpoint and your team's RBAC bindings instead of a downloaded kubeconfig. Output streams back keystroke by keystroke, the token carries the identity and scope so there is no ambient credential to steal, and that same auth path lands every command in the audit log. The thing that grants access and the thing that records it are one signed token, so the shell cannot become a blind spot.
Browser Terminal
Full command-line access. Zero local setup.
The CLI you already know
Every command you'd run locally, in your browser, against any environment.
Secure by construction
Every session runs over a TLS WebSocket with a signed, expiring JWT.
Zero local setup
No config files, no VPN, no context-switching; open a tab and you're in.
Capabilities
Everything inside Browser Terminal.
Per-environment session scoping
Each shell binds to a single environment and your role's RBAC at open time, so a viewer's JWT cannot open a mutating socket at all. Switching clusters mints a new scoped session rather than re-pointing a kubeconfig at a namespace you should not touch.
Keystroke-level output streaming
stdout and stderr stream back over the WebSocket as the process emits them, so `logs -f`, `rollout status`, and `top` behave like a native TTY. Long-running follows keep flowing instead of buffering until the command exits.
Copy, paste, and scrollback
Copy, paste, scrollback and command history all behave like your local terminal, so muscle memory carries straight over and nothing feels second-class in the browser.
Immutable per-command audit trail
The signed identity that authorizes the socket also tags each command with who ran it, in which environment, and when. There is no unlogged side channel, so the terminal reads as evidence in a review rather than a gap in it.
Server-to-cluster latency path
Because the shell executes next to the cluster's API endpoint inside the control plane, commands never traverse a home VPN or a personal laptop. Round-trips are server-to-cluster, not laptop-to-bastion-to-cluster, so interactive `exec` and log follows stay responsive.
Credential lifecycle tied to the session
Access rides an expiring JWT, so there is nothing to rotate off an offboarded engineer's machine and nothing to find in a `~/.kube` directory during an incident. Revoking a role revokes the shell; letting the token expire ends it.
How it works
A secure shell, one click away.
01
Open a terminal
Launch a shell against any environment straight from the dashboard.
02
Authed instantly
A signed JWT opens a secure WebSocket for the session.
03
Run anything
Full command-line access, with every action in the audit log.
Built for real work
Where Browser Terminal earns its keep.
The 2am pager with no tooling installed
An on-call engineer is paged on a personal device with nothing set up. They log into Kubentic, click the affected environment, and run their usual commands within seconds, with no kubeconfig, no VPN client, and no fumbling with cloud CLIs while the SLO burns.
Retiring the shared bastion host
A platform team kills its jump box outright. Instead of maintaining SSH keys, a bastion AMI, and VPN routes, access flows through per-user JWTs scoped by RBAC and every command is already logged, retiring a whole class of infrastructure and the compliance burden attached to it.
Onboarding without a setup day
A new hire needs to inspect a staging cluster on day one. Instead of a half-day installing a CLI, wiring up contexts, and requesting VPN access, they open a browser tab and get exactly the read or write access their role grants, productive before lunch.
At a glance
The technical details.
- Transport
- TLS WebSocket (wss), full-duplex, streamed keystroke by keystroke
- Authentication
- Signed short-lived JWT per session; no local kubeconfig on disk
- Authorization
- Cluster RBAC resolved at session open, scoped to one environment
- CLI surface
- A full command line: get, describe, logs -f, exec -it, apply, rollout, top
- Auditability
- Every command tagged with who ran it, where, and when
- Local requirements
- A modern browser; zero binaries, no VPN client, nothing stored locally
- Local setup
- 0
- Authenticated
- JWT
- CLI command
- Any
- VPN needed
- 0
Local setup
Authenticated
CLI command
VPN needed
FAQ
Questions, answered.
Is this a real terminal, or a limited web wrapper?
It is the real command-line running server-side inside the control plane. Commands you already rely on, including `logs -f`, `exec -it`, `apply`, `rollout status`, `top`, and `describe`, all behave as they do locally. The browser is only the terminal emulator and TTY; the CLI itself is the genuine article, not a JavaScript reimplementation of a subset.
How is a browser terminal secure enough for production?
Every session rides a TLS WebSocket authenticated by a signed, expiring JWT, and authorization resolves against cluster RBAC at open time, so the shell can only do what your role permits. There is no long-lived kubeconfig on a laptop to be stolen, and the same token that authorizes the socket writes every command to the audit log.
Is the terminal only for one tool, or a full shell?
A full shell. Tail logs, exec into containers, apply manifests, inspect resources, or run any command-line tool your role permits, all in the same session. It is not limited to a single utility.
Do I still need a VPN or a jump host?
No. the shell runs inside the control plane against the cluster's in-region API endpoint, so there is no network path for you to tunnel: no VPN client, no bastion, no SSH keys to manage. Many teams retire their shared jump host entirely once access flows through per-user scoped sessions.
Can I restrict who runs mutating commands versus read-only?
Yes. Access maps directly to cluster RBAC, resolved when the session opens. A viewer-scoped role gets a read-only shell that cannot mutate resources, while an operator role can apply and roll out. Because the terminal inherits your existing RBAC bindings, you govern it with the exact policy you already enforce on the API.
“The in-browser terminal replaced our jump host overnight. A full command line on any cluster, nothing to install, and every command lands in the audit log.”
Your first environment is
15 minutes away.
No credit card. No infrastructure expertise. Just a cloud account and a browser, and you're shipping.
Free plan · No credit card · Cancel any time