Ruust
PricingBountiesDocs
Deploy an Egg ✦
DocsShell access

Shell access

Open an interactive shell inside a running Egg, from the terminal with `ruust shell` or from the Shell tab in the dashboard, like `docker exec -it` but to a container on a Ruust host.

Sometimes you need to be inside the container: check what actually got built, read a file, run a one-off script, or open psql against a database Egg. Ruust gives you an interactive shell into a running Egg two ways, a ruust shell command in the CLI and a Shell tab on the Egg page in the dashboard. Both behave like docker exec -it: a real terminal (a PTY) attached to the process, so arrow keys, tab completion, colours, and window resizing all work.

From the terminal

Run ruust shell <name> with the name of an Egg you own. The CLI mints a short-lived session, connects over a secure relay, and drops you straight into the container. Type exit (or press Ctrl-D) to leave. You need to be signed in (ruust login) and running in a real terminal.

bash
ruust shell my-egg

# connecting to my-egg...
# root@36cb0f65a247:/app# ls
# root@36cb0f65a247:/app# exit
Open a shell in a running Egg and poke around, then exit.

From the dashboard

Open an Egg and choose the Shell tab. A terminal opens in the browser with the same access as the CLI, handy when you are not at a machine with the CLI installed. It is the same running container either way, so anything you do in one is visible in the other.

What shell you get

The session starts bash if the image has it and falls back to sh otherwise, so a slim image without bash still gives you a working shell. You land as the container's user (usually root) in the working directory the image sets, which for a repo built by Ruust is /app. For a database Egg the Shell tab and ruust shell drop you into the database container, so psql or redis-cli are right there.

bash
# On a Postgres Egg, connect to the local database:
ruust shell my-db
# psql "$DATABASE_URL"
A database Egg's shell has the engine client on the PATH.

The filesystem is ephemeral

What it can and cannot reach

  • It attaches to a *running* container, so a cold (stopped) or cracked (crashed) Egg has nothing to attach to. Get it hatched first, and if it keeps cracking on boot read the logs rather than the shell.
  • The shell runs inside the same locked-down container as your app: the usual Linux capabilities are dropped and no host paths are mounted, so you cannot reach the host or other tenants' Eggs from it.
  • Sessions are single-use and time-limited. A session token is good for one connection and the shell is closed automatically after a long idle-safe cap, so a forgotten tab does not stay open forever.
  • Environment variable values are present in the running process, as your app needs them, so treat a shell session with the same care as the secrets on the Egg. Ruust never logs those values.
Deploy on Ruust ->