Browser terminal

The browser terminal is how you get a shell inside a running GPU instance. It runs over a WebSocket from the console, so nothing to install locally.

Open the terminal

Go to Compute → GPU Instances in the console.
Click into the running instance you want to access.
Click the Terminal button in the top-right of the detail page.

A full-screen terminal opens in your browser. You're root inside the container — standard shell behavior, every command you'd expect (ls, cd, python, vim, apt, nvidia-smi, etc.) works.

Behavior and limits

Single active session per instance — opening the terminal from a second tab closes the first. Use tmux or screen inside if you need multiple panes.
Your browser tab is the connection — if the tab closes or you lose network, the WebSocket drops. Your process inside the container keeps running (it's not tied to the tab); just reopen the terminal to reattach.
Copy / paste works with native browser shortcuts (Cmd/Ctrl+C to copy the selection, Cmd/Ctrl+V to paste).
Idle timeout — connections idle for > 60 min are closed server-side. Reopen to reconnect.

Long-running jobs — use `tmux`

The terminal is your window into the container, not the container itself. A training job running in python train.py keeps running if you close the tab — but you lose visibility unless you reattach to a tmux session:

# First time:
apt-get update && apt-get install -y tmux
tmux new -s work

# Now inside tmux — run your long job:
python train.py

# Detach without stopping: Ctrl-b then d
# Close the tab. Come back tomorrow. Open the terminal:
tmux attach -t work

Best practice: run any job expected to take more than a few minutes inside tmux.

SSH access

For a real terminal, scp/rsync, VS Code Remote, or any script, enable SSH at launch:

On the launch form tick Enable SSH and paste your OpenSSH public key (ssh-ed25519 … or ssh-rsa …). Over the API that is "ssh_enabled": true plus "ssh_public_key": "…".
Once the instance is running and accepting connections — usually within a minute of the pod coming up — the detail page (and GET /gpu-instances/{id}, as ssh_command with ssh_ready: true) shows the command to run:
```
ssh -o HostKeyAlias=ecohash-instance-<id> -p <port> root@<host>
```
You connect as root, authenticated by the key you pasted; no password. Copy the command as shown: the HostKeyAlias part is what keeps SSH from warning you later (see below).

The first connection asks you to confirm the instance's host key. The detail page shows the instance's host key fingerprint; check that SSH shows the same SHA256:… and answer yes. Each instance has its own key and keeps it for its whole life, including restarts. To skip the question, use Copy known_hosts line on the detail page (or ssh_known_hosts_line from the API) and add that line to ~/.ssh/known_hosts before connecting.

"REMOTE HOST IDENTIFICATION HAS CHANGED" appears if you connect with a plain ssh -p <port> root@<host>: connection ports are reused between instances, so your computer remembers a key that belonged to an earlier instance on the same port. Use the command exactly as shown, with HostKeyAlias, and the warning doesn't appear. If you see it with that command, the key really differs from the one shown on the detail page: don't connect, and contact support.

SSH cannot be switched on for an instance that is already running — the key and the connection are set up when the pod starts. Launch a new one.

The image needs OpenSSH. Every EcoLink platform image (the entries in the image dropdown — GPU Base, GPU Jupyter, GPU Inference, CUDA Bare) has it, and SSH is up within seconds. A plain third-party image such as nvidia/cuda:… or pytorch/pytorch:… usually does not; when you enable SSH on one, EcoLink installs OpenSSH at boot (Debian/Ubuntu and Alpine based images), which adds about a minute before SSH accepts. If the image can't install it, the instance still runs — use the browser terminal — but SSH won't connect; the pod log says so.