Codara Cloud
Request access

Guides

Shell access to apps

Once shell access opens, you will be able to open a shell inside a running app, or run a single command there, to see what your code sees: its files, its environment and its network.

Not available yet

Shell access is not available yet. It opens to every plan in a coming release; this guide describes how it will work.

Open a shell

bash
$ codaracloud exec web --client my-workspace --project website --env production

This connects your terminal to the running app web. You get a normal interactive shell (bash if the image has it, otherwise sh), with resizing and Ctrl-C working as you would expect. Leave with exit.

The shell opens in the app’s own container, the one that serves your traffic. Codara picks a healthy running instance for you; you do not name a pod or a container. If the app has no running instance, the command says so and does nothing.

Run one command

Put the command after --. The output is printed in your terminal and codaracloud exits with the command’s own exit code, so it works in scripts:

bash
$ codaracloud exec web --client my-workspace --env production -- node -v $ codaracloud exec web --client my-workspace --env production -- ls -la /app
FlagMeaning
--clientThe workspace of the app. Needed when the name is not unique.
--project, --envNarrow down the app when the same name exists in several projects or environments.
--tty (-t), --no-ttyForce or turn off the interactive terminal. By default you get one when your input and output are terminals.

Without a terminal, for example in a script or a pipe, you must give a command. Anything you pipe in is passed to the command, and the exit code is 255 if the connection drops before the command finishes.

Who can use it

Shell access is for members who can deploy to the app: owners, admins and developers of the organization. It will be available to every plan once it opens. An API token needs the apps:exec scope. Every session is recorded in the activity log with who opened it and when. Codara does not keep the arguments, input or output of your commands.

A shell can read your secrets

Inside the container you can read the app’s environment variables, including secrets and database passwords. Open a shell only on apps you are allowed to debug, and never put a secret in a command argument: arguments can end up in logs on the way.

What to expect

  • It is the live app. A shell on a production environment runs next to production data. Prefer read-only commands.
  • Changes do not last. Files you create or edit live in the running container only. They are gone on the next deploy, restart or scale event. Use volumes for data that must stay.
  • One instance. If the app runs several instances, you get one of them.
  • Idle sessions close. A session with no input or output for 30 minutes ends, and you can have up to 4 open at once.
  • Restarts disconnect you. When Codara restarts the connection service, you see a message. Run the same command again.
  • Jobs are not included. Shell access is for running apps; see Jobs and cron and Logs and metrics for those.

For a private machine to work in, rather than a running app, see Codara Boxes.

Last updated