Skip to main content
Live. This area is documented as current, user-reliable behavior.

Goal

Understand what the terminal workspace does, the shell kinds and modes it offers, and how a session is established and bounded.

Prerequisites

  • A project with a running deployment, or a running managed database

Workflow

1
Open a project and go to its Operations / Terminal workspace.
2
Pick a target (a running deployment, a release image, a running preview, or a database).
3
Pick a mode: running attaches to the live container, ephemeral starts a fresh container from the release image.
4
Start the session; the browser connects over a short-lived ticketed WebSocket to the node agent.

Shell kinds

  • Application shell: a /bin/sh session inside the workload container on the node.
  • Database shell: a client session into a managed database (psql for Postgres, mysql for MySQL, redis-cli for Redis), with credentials injected for you.

Session modes

  • Running: attach to the live, already-running deployment container. Best for inspecting real state.
  • Ephemeral: launch a throwaway container from the release image (useful when the app image has no running container or you want an isolated environment). Writable volumes are off by default and require the volume-write permission.

Targets you can open

  • The active running deployment (running + ephemeral modes).
  • A release image (ephemeral only).
  • Running preview deployments (running + ephemeral).
  • Managed databases attached to the project (running shell only).

Session lifecycle and limits

Sessions are authorized with a single-use ticket and run over a WebSocket to the node agent. They are bounded by an idle timeout (default 10 minutes) and a hard maximum duration (default 1 hour), and they support a reconnect grace window after a dropped connection. All of these are configurable in the terminal policy.

Why a shell can fail to open

  • No running deployment: running mode needs a deployment in the running state; otherwise use ephemeral.
  • No shell in the image: distroless/scratch images have no /bin/sh — use a one-off command or an ephemeral session from a shell-capable image.
  • Permission or production gating: see Access and permissions, and Production safeguards.

Expected result

You get an interactive shell scoped to the chosen target, subject to your permissions and the project terminal policy.

Access and permissions

How terminal permissions are derived from team role, project ownership, per-user grants, and platform admin, and what each permission unlocks.

Production safeguards and approvals

How a target’s environment is classified, why production access is gated, and the reason/approval flow members must follow.

Runbooks and one-off commands

Run versioned platform and project runbooks, and execute ad-hoc one-off commands, within the project terminal policy.