SSH and shell access to a running service
What a shell inside a running service is for, why anything you change by hand is lost on the next deploy, and where the guide for connecting to one lives.
What this covers
Shell access drops you inside the running container, where you can list files, check what an environment variable actually resolved to, run a database migration by hand, or confirm that the build produced the file your start command expects. It is the fastest way to answer “is it actually there”.
Voroa offers this on paid plans. To set it up, follow SSH access: open a terminal inside your running service - you add a public key once, then connect with the address shown on your service’s SSH access tab.
The one thing to know before you use it
Anything you change by hand inside the container is lost on the next deploy. The container is rebuilt from your repository, so an edited file, an installed package or a patched config survives only until something triggers a build - which makes it easy to fix a problem in a way that disappears an hour later and that nobody remembers doing.
Use a shell to find out what is wrong. Fix it in your repository, then deploy.
What people use a shell for
- Check a file exists. Confirm the build produced the folder or binary your start command runs.
- Read the real environment. Print one variable to see what your app actually received, without printing the rest.
- Run a one-time command. Apply a migration, clear a cache or create an admin user by hand.
- Test a connection from inside. Reach your database or an outside API from the same network your app uses, to tell a network problem from a code problem.
When a shell is not the right tool
- To see why a deploy failed, read the build and deploy log first: a container that never started has nothing to connect to. See deploy status.
- To run a command on a schedule, use a scheduled task, not a shell session left open.
- To change a setting for good, change it in your repository or in Environment, then deploy.