Run commands in services

Use a running replica to inspect a live process, or a separate one-off container for a migration or import. A separate run leaves serving replicas untouched, but its command can still change databases or other resources it connects to.

Before you start

• Have a deployed runtime image containing a shell. Static sites have no container to enter.
• A browser terminal, SSH session or exec command needs a running replica. Wake or scale up a stopped service first, or choose a separate run.
• For MCP, use a product-scoped token with Deployment admin for executing commands or registering/deleting SSH keys. Reading the SSH command or key list requires read.
• Ensure commands can finish without input when using the non-interactive command action.

1. Choose the session

A heavy command in a running replica competes with application requests. Jobs only support the separate-run command mode; they have no persistent replica for an interactive shell.

2. Run the command

For the browser terminal, open Service → Terminal. Lepsto uses bash when present and otherwise falls back to sh. Sessions close after 30 minutes without activity or four hours total. At most three sessions can be open, with only one per replica.

For a one-off command, choose Run command at the foot of the service panel, or deployment_service_exec. Supply serviceId, command, and the mode:

• mode: "exec" is the default and runs in an existing replica.
• mode: "job" starts a separate container; the service itself need not be running.

Commands run through /bin/sh -c, so pipes, redirection and && work if the image includes the needed shell and programs. The result returns standard output, standard error and the exit code as text.

The default command timeout is five minutes; timeoutSec accepts 1–1800 seconds. Output retains the last 256 KiB of each output stream. Earlier output is dropped and marked truncated. For larger output, filter it or write it to persistent storage accessible to the command.

Verify it works

Check the exit code and output, then inspect the intended result. For a migration, verify the expected schema or records through the application. An exit code alone cannot show that the command changed the right environment.

For inspection, confirm the command ran against the intended service and close the session when finished. Do not print secret variable values into output you intend to share.

Connect through SSH

1. Open Environment → Settings → SSH keys → Add key, or call deployment_ssh_key_register. Provide a name such as work-laptop and the public OpenSSH key line (ssh-ed25519 … or ssh-rsa …). Keep the private key on your machine.
2. Get the service’s exact command with deployment_ssh_command. It includes the host and the environment/service username.
3. Run the returned command with your standard ssh client. Confirm you reach a running replica, then exit when done. Appending a command runs just that command and returns.

Authentication is public-key only. A registered key belongs to the product and works across its services. The key list shows label, fingerprint, type and last-used time. Deleting it with deployment_ssh_key_delete takes effect immediately.

SSH does not support scp, sftp or port forwarding. Put files in the image or persistent storage; run commands within the environment to reach private services.

What persists

Files written to the container filesystem disappear on replacement, restart or scale-down. Separate runs start from the image again and do not share temporary files with one another or serving replicas. Use a volume or database for persistent data.

Exporting a shell variable changes only that shell. It does not change the application process or future replicas. Set service variables and redeploy to change lasting configuration.