Using cuda servers for remote development

When your laptop needs more muscle, you get a personal box on the cuda-dev hosts — your own container with the GPU, where you can edit, build, and run Claude. This page covers working remotely on it; for first-time setup (your key, ssh config, tmux, Claude) start with getting started.

Connecting

When your box was provisioned you were sent a Bitwarden Send link with your SSH key and a ready-to-paste ~/.ssh/config snippet (the full walkthrough is in getting started). Once that’s in place:

ssh cuda-dev2-kvdb

You log in to your own container as the dev user — never the host. You need to be on the office network or the VPN.

VS Code

Install the Remote - SSH extension and connect to your cuda-dev2-kvdb host — the same alias from your ssh config, key-based, no password. Open your project folder and the editor and its integrated terminal run on the container.

Using the GPU

The GPU is yours directly — no setup, no Docker:

nvidia-smi

CUDA, PyTorch, TensorFlow and friends use it natively. Install your project’s dependencies in your container (a venv or uv) and run as normal.

Docker

Docker is available for containerized workflows; the daemon runs as root in your container, so use sudo:

sudo docker run --rm hello-world

GPU passthrough into Docker (docker --gpus) is not set up on the dev boxes, so use the GPU directly as above. If you genuinely need the GPU inside a Docker container, ask infra.

Long-running jobs

Your session lives on the box, so run inside tmux (or mosh) and your work survives a disconnect — reattach later from anywhere. See the remote session management guide.

Moving your work to another box

Your boxes are independent: nothing syncs between them. To continue on another host (say from cuda-dev-kvdb to cuda-dev3-kvdb), pull your work over the office LAN from the destination box. The same key opens all your boxes, so forward your ssh agent:

# On your laptop: load your key into the agent, then connect with -A
ssh-add ~/.ssh/cuda-dev-kvdb
ssh -A cuda-dev3-kvdb

On the new box, pull each directory you want to take along. Boxes resolve each other by name with a .lan suffix:

rsync -a --info=progress2 dev@cuda-dev-kvdb.lan:myproject/ ~/myproject/

Re-run the same rsync to resume an interrupted transfer or pick up last-minute changes. Copy your repos and data directories, not credentials or AI config (~/.ssh, ~/.claude, /etc/work): those are provisioned per box. Running tmux sessions stay behind on the old box.

Resuming your AI sessions

Claude and Codex conversations resume on the new box. After moving the work directories they ran in, copy the session markers and transcripts, then let the restore tool reopen everything stale in a detached ai-restore tmux session:

rsync -a dev@cuda-dev-kvdb.lan:.local/state/ai-sessions/ ~/.local/state/ai-sessions/
rsync -a dev@cuda-dev-kvdb.lan:.claude/projects/ ~/.claude/projects/
rsync -a dev@cuda-dev-kvdb.lan:.codex/sessions/ ~/.codex/sessions/
restore_ai_sessions.sh
tmux attach -t ai-restore

Sessions still running on the old box count as stale here and reopen too; quit them there first if you do not want the same conversation open twice.

Per-project sessions

To work on a specific project with scoped, isolated credentials, use work <project> — it gives that project its own throwaway container. That is a separate, more advanced topic.