Web Shell

The Web Shell is a full terminal into your running application's container,

right inside the dashboard. Open it from any deployed project at

Project → Shell to inspect the filesystem, read environment, tail logs,

run one-off scripts, or debug a misbehaving deploy — without SSH, kubectl,

or any local tooling.

Every command runs inside the exact container that is serving your app,

so what you see is the real runtime: the same filesystem, the same

environment variables, the same processes.

Opening a shell

1. Deploy your project at least once. The shell attaches to a running

container, so a project that has never deployed has nothing to attach to.

1. Go to Project → Shell.
2. Start typing. The prompt shows your current container and working

directory.

If a project has multiple containers (for example an app plus a sidecar),

you can target a specific one by setting the container field; leaving it

blank uses the primary application container.

Two modes

| Mode | What it's for | Availability |

| --- | --- | --- |

| One-shot commands | Quick, bounded commands — ls, cat, env, df -h, a migration script | All plans |

| Interactive streaming | Long-running or chatty commands — npm install, a build, tail -f, a REPL — with live output and an elapsed timer | Pro & Enterprise |

One-shot commands

Each command is executed, its combined stdout/stderr is returned, and the

exit code is shown. The shell is stateful for your working directory:

cd into a folder and the next command runs from there, so you can navigate

the filesystem naturally even though each command is technically independent.

Interactive streaming

On Pro and Enterprise, commands stream their output live as they run,

with an elapsed-time counter — ideal for installs, builds, or following a

log. Lower tiers run the same commands in one-shot mode and receive the full

output when the command finishes.

Quick commands

The shell ships with one-click shortcuts for the commands you reach for most

when debugging a container:

1. ls -la — list files in the current directory
2. pwd — print the working directory
3. env — show the runtime environment
4. cat package.json — inspect the project manifest
5. df -h — disk usage
6. free -m — memory usage
7. ps aux — running processes

History & transcript

1. Command history is remembered per project (up to the last 100

commands) and persists across sessions — use the up/down arrows to recall

previous commands.

1. The transcript keeps your recent commands and their output on screen so

you can scroll back through a debugging session, and can be downloaded

as a text file for sharing or attaching to a support ticket.

Permissions

The Web Shell can change your running app, so access is restricted:

1. Owners and Developers can run commands.
2. Viewers cannot — the shell is read-only-to-them by design.

All commands are attributed to your user in our audit logs. The engine's

privileged credentials never reach the browser — every command is proxied

through Launchverse's API, which authenticates you, enforces your role, and

applies the limits below before forwarding the command to the container.

Limits & safeguards

1. Burst limit: up to 40 commands per minute, per project, to prevent

runaway automation.

1. Daily limit (per plan):

| Plan | Commands / day |

| --- | --- |

| Free | 200 |

| Student | 1,000 |

| Pro | Unlimited |

| Enterprise | Unlimited |

1. Command length: up to 4,096 characters per command.
2. Destructive-command warning: commands that look destructive — for

example rm -rf, mkfs, dd if=, DROP DATABASE/DROP TABLE,

fork bombs, shutdown/reboot, or writing to a block device — surface a

confirmation prompt before they run. This is a guard rail, not a jail:

you can still run them deliberately, so treat the production container with

the same care you would a production server.

Tips

1. Use the shell to confirm an environment variable actually reached the

container (env | grep MY_VAR) when a deploy behaves unexpectedly.

1. Run database migrations or one-off maintenance scripts directly against

the live app.

1. Check disk and memory (df -h, free -m) when a container is being

recycled or running slowly.

1. Changes you make to the filesystem at runtime are not persisted across

redeploys — the next deploy starts from a freshly built image. Persist

anything important to a database or a mounted volume.