Interactive shell

Sometimes logs and metrics aren't enough and you just need to poke around inside a running service. Appentic can spawn an interactive shell inside any service (web service, worker, or a disposable sidecar sharing your service's filesystem and environment) with one click. You don't need SSH keys, jump hosts, bastion configuration, or port forwarding. You also don't need to bake a shell into your production image.

Opening a shell

From any service's dashboard, click Shell. A terminal opens in a new browser tab, already logged into a fresh container that shares your service's image, its environment variables, and its network access. That means anything your running service can reach (the database, the key-value store, internal APIs) the shell can reach too.

The shell boots in under a second and drops you straight at a prompt. There's nothing to install locally: the terminal is a web component running over a websocket to the container.

What you can do

The shell is the right tool when you need to:

• Inspect environment variables with env to verify a config change took effect.
• Run a database migration or a one-off backfill script.
• Drop into your language's REPL (node, python, irb, go run scripts/repl.go) to poke at the live state.
• Install a debugging tool temporarily with your package manager (apt, apk, pip, npm) without rebuilding the image.
• Run curl against an internal service to verify that service-to-service connectivity is working.

What's ephemeral

The shell container is disposable. When you close the tab, the container is destroyed along with any files you created in it. If you need to keep something around, write it to your database, your key-value store, or a local file and scp it out. This is a safety property, not a limitation: it means a shell session can never accidentally drift your production filesystem away from the image.

Permissions and auditing

Only workspace members with the Operator or Admin role can open shells. Every shell session is audit-logged with the operator's identity, the start and end time, and every command typed inside the session. This log is visible to workspace admins from Settings → Audit log, so you can answer "who ran what, when" for any incident.