Add a key

Add it in the console

1. Open SSH Keys in the console, at /keys.
2. Select Add SSH key.
3. Enter a Name, up to 64 characters — work laptop, desktop, whatever tells you which machine this is. The name is a label for you and is not sent to the instance.
4. Paste the entire contents of your .pub file into Public key.
5. Select Add key.

The key appears in the list with its SHA256 fingerprint and when it was added.

Paste the whole single line, from ssh-ed25519 through the trailing comment. Superheat checks the type against the accepted list and decodes the key material, so a truncated paste, a private key, or an unsupported algorithm comes back as INVALID_SSH_KEY. Adding a key you already have returns DUPLICATE_SSH_KEY, matched on fingerprint rather than on name.

Keys are per user, not per organization

An SSH key belongs to your user account. It follows you into every organization you are a member of, and switching organizations does not change what is in the list.

Situation	What happens
A teammate opens their SSH Keys page	they see their own keys, never yours
You switch to another organization	your keys are still there, unchanged
Someone joins your organization	they add their own key; nothing is shared
Someone is removed from the organization	their keys stay on their account

There is no organization-wide key, and an instance is deployed with exactly one key: the one you pick on the deploy form.

The key is baked in at launch

The Deploy page has an SSH key selector. It defaults to No key (web terminal only), so you have to pick your key deliberately.

The key you pick is written into the instance's authorized keys while the instance is being created. That is the only moment it happens.

Action	Effect on the instance
Deploy with a key selected	that key is installed and SSH works, in the ssh, jupyter and vm launch modes
Deploy with no key selected	no key is installed, for the life of that instance
Add a key to your account afterward	existing instances are unaffected
Stop the instance and start it again	it keeps the key it launched with; nothing is re-read
Delete a key from the SSH Keys page	instances already running keep it; new deploys can no longer select it

The key only reaches the container when the template's launch mode boots the Superheat entrypoint — ssh, jupyter and vm. An args template runs the image's own entrypoint, which does not start sshd, so selecting a key there gives you nothing to connect to. See Launch modes.

SSH on your instance is key-only. There is no password to fall back on.

Add your key before you deploy, not after

No API call, console action, or restart installs a key on an instance that already exists. If you deploy without one, redeploying is the only way to get a shell.

If you forgot

The instance is still yours and still billing — you have lost access, not the machine or the disk.

1. Add your key on the SSH Keys page now, so the next deploy has it.
2. If the template launches JupyterLab, open it from the instance page and use its terminal to copy anything you need off the disk.
3. Destroy the instance and deploy again with the key selected.

Destroying deletes the disk permanently. Read Stop vs destroy before you do it.

Stopping and starting does not help. The key is decided when the instance is created, not when it starts.

From the API

Method	Path	What it does
GET	/v1/ssh-keys	list your keys with their fingerprints
POST	/v1/ssh-keys	add a key
DELETE	/v1/ssh-keys/{key_id}	remove a key

{
  "name": "work laptop",
  "public_key": "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIJ8mQ2sT9vXbN1kR4pLwZ0aYcE7hJ6uD3fGgH5iKmNoP you@example.com"
}

The id returned is what you pass as ssh_key_id when you create an instance.

These are account endpoints, so they take a session token only — an organization API key (shk_…) is rejected on all three. An API key can still pass ssh_key_id when deploying; the key it names has to belong to the user who created that API key. See Authentication.

With the key added, go on to Deploy, then Connect over SSH.