Hey everyone! We’ve recently made two changes to
fly ssh console and
fly console to give you a better experience:
The shell is chosen from
When no command is specified (i.e.
fly ssh console without
fly console without a
console_command defined), both of these by default open a Unix shell. The shell was previously hardwired to
/bin/sh, which is very common but not as user-friendly as alternatives like Bash. In fact, you may have found yourself frequently typing out
fly ssh console --pty -C /bin/bash (it’s even in our docs!) or running
bash as your first command after connecting.
We’ve updated our built-in SSH server to choose the shell from your container image’s
/etc/passwd if available, falling back to
/bin/sh if not. So, for example, if your app uses a Debian-based image, you’ll get
/bin/bash by default when you run
fly ssh console!
The working directory is now your image’s
The initial working directory for commands run over SSH was previously
/. We just rolled out an update to make it your container image’s
WORKDIR instead (if set). It’s the directory that your app is started in, and often the directory with all your code and scripts, so it makes sense to start there. (It also matches
docker exec’s behavior.)
fly launch generates
Dockerfiles with an appropriate
WORKDIR for a number of common frameworks. For example, if you’re running a Rails app,
WORKDIR will be set to
/rails, where your code was copied.
This also means that if you want to execute scripts with
fly ssh console -C, you probably don’t have to type as much. If you have been running
/rails/bin/rails, you can just use
bin/rails now, like you may already be doing for local development.
You may need to deploy to see these changes
These changes were made by modifying our built-in SSH server and our
init process, so only new or updated machines will have them. Practically speaking, once you deploy a new version of your app, you should be good to go.