SSH and Shell Access

You can initiate a shell session to your Render service from its Shell page in the Render Dashboard:

If your service is scaled to multiple instances, you can connect to a specific instance using the Instance dropdown.

You can also SSH into your services from the terminal after completing setup.

Compatible service types

Support for shell access varies by service type:

SSH setup

1. Generate an SSH key pair

Skip this step if you already have an SSH key on your machine that you want to use.

1. Run the following command to generate an Ed25519 key pair in the ~/.ssh directory:

   You can optionally use a different key type.

2. The command prompts you to provide an optional passphrase for your private key (recommended for added security).

3. The command generates two files in your ~/.ssh directory:

   • ~/.ssh/id_ed25519 (private key)
   • ~/.ssh/id_ed25519.pub (public key)

Your private key is a secret credential. Don't share it with anyone.

To enable SSH access, you'll share the public key with Render.

2. Add your public key to your Render account

1. Open your Account settings page in the Render Dashboard.

2. Find the SSH Public Keys section and click + Add SSH Public Key. The creation dialog appears.

3. Provide a descriptive Name for the key (e.g., "Personal Laptop").

4. Copy the full contents of your public key file (ends in .pub) to your clipboard.

   On macOS, you can use the pbcopy command to copy the file to your clipboard:

5. Paste your public key into the Key field:

   

6. Click Add SSH Public Key button to save your key.

All set! You're ready to start an SSH session.

Starting an SSH session

SSHing into a Docker-based service? See Docker-specific configuration.

After completing SSH setup, you can start SSH sessions from your terminal using the Render CLI, or by running the ssh command directly.

Select a method from the tabs below:

Connecting to a specific instance

By default, SSH sessions connect to a random running instance of your service. To connect to a specific instance, include that instance's 5-character slug in the username of your SSH command:

As shown above, you append the instance slug to the service's ID (separated by a hyphen) to form the complete SSH username.

Instance slugs are visible in your service's logs and application metrics. You cannot SSH into an instance that is no longer running.

Troubleshooting permission failures

If you receive a "Permission denied" error, Render rejected the incoming SSH session. Take the following steps first to troubleshoot this issue:

Confirm which SSH key you're using

Add the "verbose" flag (-v) to your SSH command to get more details about which key is being used:

Confirm which keys are attached to your Render account

1. List any keys you have loaded into the ssh-agent.

   This should print out a long string of numbers and letters.

2. Open your settings page in the Dashboard and find the list of SSH public keys.

3. Compare the list of SSH keys with the output from the ssh-add command.

If you don't see your public key listed, you can add it to your account.

Starting an ephemeral shell instance

Ephemeral shell instances require a compatible service running on a paid compute plan with at least one successful deploy.

You can spin up a temporary, isolated instance of your service to run one-off commands, debug issues, or inspect your environment without affecting your live deployment.

An ephemeral shell instance runs your service's image, but does not receive any traffic or run your service's start command.

After you disconnect from the SSH session, Render immediately deletes the ephemeral instance. If you forget to disconnect, Render automatically cleans up the instance after 24 hours. You are billed for the duration of your SSH connection at the instance's rate.

1. Install and log in to the Render CLI if you haven't already.

2. Run the following command with the --ephemeral (or -e) flag:

   Render spins up a new ephemeral instance with your service's latest build and starts an SSH session.

   By default, the ephemeral instance uses the same compute plan as its base service. You can specify a different compute plan with the --plan flag:

   The --plan flag requires v2.20.0 or later of the Render CLI.

   On older CLI versions, ephemeral shell sessions for a service shared a single instance limited to 0.25 CPU and 256 MB RAM.

Render's public key fingerprints

Public key fingerprints can be used to validate a connection to a remote server.

Render’s public SSH key fingerprints are as follows:

You can also directly add Render's public keys to your $SSH_DIR/known_hosts file. Render's full set of entries is as follows:

Usage details

Supported key types

Render supports the following key types:

• ed25519
• ecdsa
• rsa

Render also supports U2F/FIDO hardware authenticated keys like a YubiKey.

• ed25519-sk
• ecdsa-sk

Docker-specific configuration

If your service runs a Docker image, additional configuration is required for it to accept SSH connections:

1. Make sure your image does not run its own SSH server, nor any other service on port 22.

2. Make sure your Dockerfile creates a ~/.ssh directory for the running user with the correct permissions (chmod 0700).

3. If the running user is not the root user, that user must have shell access.

   • If your Dockerfile references a parent image, you will need to perform these steps in a Dockerfile that you control, making use of the USER instruction to change back to a root user and usermod (or equivalent) to modify the non-root user, like so:

Additionally, some configurations are not supported:

• If your Dockerfile specifies a root user, the account cannot be locked. Use usermod --unlock root or passwd -u root to unlock the account.
• If your service uses a persistent disk, you must not mount it to the $HOME directory of the running user.
• Minimal ("distroless") images do not support SSH or dashboard shell sessions, because they omit the core utilities required for SSH.

Cron job connections

When you connect to a cron job from the dashboard shell, Render spins up a new, temporary instance of the service and connects to it. This instance includes your cron job's latest build and configuration. It does not automatically execute the cron job's command. After you close the shell session, Render deprovisions the instance.

It is not possible to connect to the actual cron job instances that run as part of your cron schedule.

Automatic session closure

Render automatically closes a service's active SSH sessions in the following cases:

• The service is redeployed or restarted for any reason.
• Render is scheduled to perform maintenance on underlying infrastructure that enables SSH connections.
  • In this case, Render gives existing connections one hour before automatically closing them.

For long-running commands, consider spinning up a one-off job instead of SSHing into an active instance.

Memory usage

SSH and dashboard shell sessions use the same memory pool that's allocated for your service instance. Using SSH requires about 2 MB of memory, plus about 3 MB for each active session (not including memory used by processes executed during the session).

As an example, let's say we SSH into one service instance from two different computers to run bash. In this case, memory usage would look like this:

• 8 MB for SSH
  • 2 MB for SSH access
  • 2x3 MB for the two SSH sessions
• 7 MB for bash
  • 2x3.5 MB for the two bash processes

Total memory usage in this case is about 15 MB.