Develop on a cloud GPU with VS Code Remote-SSH

The Remote-SSH setup that works first time is a config entry that names the provider's login user, the VM's IP and your key, because the extension reads the same file as the ssh command and fails in the same ways. Get plain ssh working first, add one Host block, and VS Code opens the GPU machine as if it were a local folder, with the terminal, debugger and extensions running on the VM.

Test plain ssh before you open VS Code

Microsoft's Remote-SSH documentation starts with the same advice: confirm you can connect from a terminal with ssh user@hostname, then add VS Code. Copy the exact command from the deployment in the dashboard. The user depends on the provider:

If the first attempt is refused within a minute of Running, some providers mark a VM ready before SSH answers. The connection refused page has a retry loop. The SSH guide covers keys in full.

Then install the Remote - SSH extension, ms-vscode-remote.remote-ssh. Your computer needs an OpenSSH-compatible client. On Windows that means the Windows OpenSSH client, and the documentation says PuTTY is not supported. The documentation says the VM needs Bash, tar and either curl or wget, which stripped-down images can lack, and Ubuntu is on its supported list.

Put the VM in your SSH config

Run Remote-SSH: Open Configuration File from the Command Palette, which you reach with F1, and add a block. Remote-SSH: Add New SSH Host does the same and accepts the full ssh command from the dashboard. On Windows the file is C:\Users\YOU\.ssh\config.

Host gpu
    HostName YOUR_VM_IP
    User ubuntu
    Port 22
    IdentityFile ~/.ssh/deploygpu
    IdentitiesOnly yes
    ServerAliveInterval 30

Every launch gets a new IP address, so HostName is the one line you change each time. ServerAliveInterval 30 makes SSH ask the server for a reply after 30 quiet seconds, per the ssh_config manual, which helps keep an idle connection from being dropped on the way. If SSH warns UNPROTECTED PRIVATE KEY FILE, the documentation's fix on Linux and macOS is chmod 600 on the key file. On Windows it points to the Win32-OpenSSH wiki.

Connect and open a folder on the VM

Run Remote-SSH: Connect to Host and pick gpu. VS Code installs its server on the VM, shows progress, and writes a detailed log to the Remote - SSH output channel. By default the extension downloads the server on the VM, which needs outbound HTTPS on port 443 to update.code.visualstudio.com and vscode.download.prss.microsoft.com. If the VM cannot reach them, it falls back to downloading on your computer and transferring the server, which the remote.SSH.localServerDownload setting changes. Then choose File, Open Folder, and any terminal you open runs on the VM. Run nvidia-smi in it before anything else.

The server lives in ~/.vscode-server on the VM, and the extensions you install on the SSH host live on the VM too. Stop deletes the disk, so every new launch starts without either. The documentation has a setting that installs a list of extensions on every host you connect to, in your settings.json:

"remote.SSH.defaultExtensions": [
    "ms-python.python"
]

The extension ID comes from the Python extension page. Add the IDs of whatever else you rely on, and the first connection to each new VM reinstalls them for you.

Forward ports for notebooks and servers

Anything you run on the VM should listen on 127.0.0.1, because DeployGPU does not firewall VMs and Hyperstack VMs are created with inbound traffic open. VS Code reaches those services through the SSH connection. Choose Forward a Port from the Command Palette, or use the Add Port button in the Ports view, and VS Code tells you which local port maps to the remote one. To keep a forward for good, add LocalForward lines to the same block, as the documentation shows:

Host gpu
    LocalForward 127.0.0.1:8888 127.0.0.1:8888
    LocalForward 127.0.0.1:8000 127.0.0.1:8000

Port 8888 suits a Jupyter server you started yourself and 8000 suits a model server such as the one in the vLLM guide. The setting remote.restoreForwardedPorts makes VS Code remember the ports you forwarded by hand. The port forwarding guide covers tunnels without VS Code.

Keep long jobs alive when the window closes

A job started in a plain SSH session dies when the connection drops, and I treat VS Code's terminal the same way. Start anything that must outlive your connection inside tmux, as the keep jobs running guide shows, and use VS Code as the way you watch it. The documentation also lists a limitation worth knowing on a GPU box: if you clone a repository over SSH and your key has a passphrase, pull and sync in VS Code may hang when it runs remotely, so use a key without a passphrase, clone over HTTPS or run git push in the terminal.

Fix the usual Remote-SSH failures

The Remote-SSH output channel shows which of these you are looking at, so open it before you change anything.

What it costs and what Stop deletes

The VM bills at its hourly rate whether VS Code is connected or not, and DeployGPU has no idle timer, so closing the window does not stop the meter. Stopping deletes the disk, including the server in ~/.vscode-server and any code you did not push, so commit and push before you stop. The stop guide has the checklist.