Skip to content

Terminal

A real browser PTY into your cluster context with the standard CLI tooling pre-installed, no local setup required.

Tier: Free

What it does

The Terminal is a full xterm.js terminal running in the browser, backed by a real PTY with a pre-configured KUBECONFIG for the current cluster. It supports multiple concurrent session tabs, each an isolated bash subprocess, and copy-on-select — highlighting text copies it to your clipboard automatically, without a separate keystroke.

Node.js is in the image and npm's global prefix points at $HOME/.npm-global, which lives on the PVC-backed home directory, so npm i -g <pkg> installs any CLI you want without root and it survives both new sessions and pod restarts.

A short-drop reconnect keeps a refresh or brief network blip from losing your session — the server holds the PTY for about two minutes after the socket detaches (TERMINAL_SESSION_TTL, default 120s), replaying the output buffer so the shell state and scrollback survive. Past that window the session is reaped and you start a new one. Opening the Terminal tab does not by itself spawn a shell; starting a session is an explicit action, and each session belongs to one account and one browser tab, so a duplicated tab can't silently attach to someone else's shell.

The UI shows a memory gauge for the terminal container as a whole (used / limit), which surfaces as a warning as it approaches the cap. Every session in the pod draws from that one pool: memory is bounded by the container's cgroup limit rather than per session. A per-session virtual-memory cap would be the wrong instrument: kubectl, helm and k9s all reserve a large virtual address space at startup regardless of how much memory they go on to use, so such a cap refuses the tools you need without bounding real consumption.

Each session is also capped on how many processes it may start (PTY_MAX_PROCS, default 512). Linux applies that kind of cap per user account across the whole node, not per container, so on a busy node the cap is measured against what the node is already running and the session gets its full allowance on top. If you are on a release before 1.1.1 and a shell reports bash: fork: Resource temporarily unavailable, that is this limit; upgrading resolves it, and raising PTY_MAX_PROCS does not.

The session's KUBECONFIG uses the agent pod's own ServiceAccount token, so the shell has exactly the permissions that account was granted and nothing more. On a default install that means no write verb on your workloads, so kubectl delete, apply and similar are refused by the API server; write verbs are granted only when the chart is installed with rbac.allowWrites=true (default false). The one place the shell can write regardless is KubeManta's OWN namespace, where the account manages its own Secrets — that is also a namespace the product blocklists, so it is not somewhere you would be working.

Expert Mode does not change the shell's credentials. It governs the agent's own privileged actions, which run in a separate expert-exec pod the terminal cannot reach, and it takes two steps: expertMode.enabled=true at install to deploy that pod, then the runtime toggle in the terminal header bar, which is off by default. While it is on the terminal marks the state clearly, so you always know whether it is active.

Setup

Open additional session tabs with the + button in the session bar. Run kubectl, helm, k9s, or any standard Linux tool against your cluster directly.

Terminal writes are deliberately ungoverned compared with every other write path in the product — there is no approval token, no blast-radius window, and no circuit breaker on commands typed into the shell. The terminal is kubectl, and a blast limit on a human's own shell would, by construction, cut off the operator partway through the incident they opened it to fix. The compensating control is visibility, not restriction: every submitted command is captured, attributed to an account, and retained for audit, and opening a session is itself audited.

Troubleshooting

If a session appears "stuck" after a network blip or a laptop sleep, wait for the ~120s reconnect window (TERMINAL_SESSION_TTL) before assuming the shell is gone — reconnecting inside that window replays the output buffer and restores scrollback. Once the window has passed, the session is reaped server-side and the only option is to start a new one; nothing recovers a shell past that point. If a connection keeps dropping before you can act, check that your proxy or load balancer isn't closing idle WebSockets — the client pings every 25s to keep them open. If kubectl delete or apply fail from inside the terminal with a permissions error, the ServiceAccount does not hold the write verb: a default install holds no write verb on your workloads, deliberately, and granting terminal writes means reinstalling with rbac.allowWrites=true. Expert Mode is not the flag here and turning it on will not change the result.

Generated from KubeManta 1.2.0 — this page is rendered from the product's own documentation, so it cannot drift from what ships. Manifest built 2026-09-12T02:14:45Z.