PodWarden
User ManualPodWarden

Quake Terminal

Admin-only drop-down command overlay for running slash commands, pw helpers, and kubectl against any cluster

What it is

The Quake Terminal is an admin-only overlay that drops down from the top of the UI when you press the backtick key. It lets you run commands directly against any cluster without leaving the page you are on.

Quake terminal overlay open, showing the command input and an empty output area
The terminal drops down as a 50 vh overlay from the top of the screen

Three categories of commands are available:

  • Slash commands — built-in terminal operations (/help, /clear, /system, /use)
  • pw helpers — PodWarden convenience commands (pw clusters, pw apps, pw doctor)
  • kubectl — arbitrary kubectl commands routed to the cluster in the current URL or pinned with /use

Output streams over SSE. System events from the backend Kubernetes client appear interleaved as dimmed lines between command output blocks.

How to enable

The terminal is off by default. To enable it:

  1. Go to Settings → System and scroll to the Quake Terminal toggle.
  2. Switch it on.
Settings System page showing the Quake Terminal enabled toggle
The Quake Terminal toggle in Settings → System — requires admin role

The terminal.enabled system-config flag must be true AND the requesting user must have the admin role. Both conditions are enforced independently on the backend and the frontend. Enabling the flag as a non-admin has no effect. The change takes effect immediately — no page reload required.

How to open and close

ActionResult
Press ` (backtick) from any pageOpens the terminal
Press EscCloses the terminal
Press ` again with an empty inputCloses the terminal

The backtick trigger is suppressed when focus is inside a text input, textarea, or CodeMirror editor, so it does not interfere with editing forms or YAML fields elsewhere in the UI.

Commands

Slash commands

Terminal showing the output of /help, listing all available slash commands
/help lists every available command with a short description
CommandWhat it does
/helpLists all available commands
/clearClears the output area
/system onEnables display of dimmed system-event lines in the output
/system offHides system-event lines
/use <cluster_id>Pins a cluster context for subsequent kubectl commands

pw helpers

Terminal showing the output of pw clusters, listing all registered clusters with their status
pw clusters lists all registered clusters — useful for finding a cluster ID to pin with /use
CommandWhat it does
pw clustersLists all registered clusters with their IDs and status
pw appsLists applications deployed across all clusters
pw doctor <host>Runs the Doctor health check against the specified host

kubectl

Any kubectl command is accepted. The cluster context is resolved in this order:

  1. The cluster UUID in the current page URL (/clusters/<uuid>/...)
  2. The cluster pinned with the last /use <cluster_id> command in this session

If neither applies, kubectl commands return no cluster context — navigate to a cluster page or run /use <id>.

Examples:

kubectl get pods -n my-namespace
kubectl describe node worker-01
kubectl rollout restart deployment/my-app -n production

Output area

Each command produces a block containing:

  • A status badge (success or error)
  • The full command output
  • A copy output button

Dimmed lines between blocks are system events emitted by the backend Kubernetes API client during the command execution. These are visible by default; toggle them with /system off.

Security

  • Admin-only, dual enforcement — the terminal.enabled flag and the admin role are checked independently on both the backend and the frontend. A non-admin user who manually sets the flag via the API still receives a 403 on every command request.
  • No shell execution — the terminal does not provide a shell. Slash commands are matched against a fixed dispatch table. kubectl arguments are split as tokens, not shell-evaluated; shell operators (|, >, ;, &&) are not interpreted.
  • Input cap — commands longer than 4096 characters are rejected before they reach the backend.
  • Cluster scoping — kubectl commands are routed to the cluster in the current URL or the pinned cluster; there is no mechanism to target an arbitrary host outside of the cluster registry.

What is not yet available

The following capabilities are deferred to future releases:

  • Per-command RBAC (currently all-or-nothing at the admin level)
  • Audit-DB persistence for terminal commands. A planned audit subsystem will eventually capture every operator command, joining the existing doctor_executions log and MCP audit trail into one searchable event stream.
  • Rate limiting on kubectl throughput
  • MCP integration (exposing terminal commands as MCP tools)

See also