A PyTorch Jupyter GPU cloud setup should take minutes, not an afternoon of driver installs. Cloudj ships a PyTorch + JupyterLab template for exactly this: a PyTorch image on a rented GPU, with JupyterLab you can open from the instance page. This guide walks through the template from deploy to cleanup: opening JupyterLab, the 12-hour session rule, the SSH tunnel alternative, checking that PyTorch sees the GPU, moving large files the right way, and keeping your notebooks backed up.
If you are a student on a tight budget, the Jupyter notebook GPU guide for students adds habits for keeping costs low.
The three templates, briefly
| Template | When to use it |
|---|---|
| Ubuntu 22.04 + CUDA (SSH) | You want a clean base and will install everything yourself |
| PyTorch + JupyterLab | You want PyTorch ready and a notebook interface |
| Custom image | You need your own public Docker image; requires a higher account level |
This article is about the second. If you outgrow it, the custom Docker image guide shows how to bring your own environment.
Step 1: deploy with the template
- Open the GPU deploy page and pick a model. Consumer cards such as the RTX 4090 are open to new accounts.
- Optionally enter country codes in the Country field to pick a nearby host. Stock changes during the day; if nothing is listed, add neighbouring codes.
- Choose PyTorch + JupyterLab as the template.
- Set the disk size. It must meet the template minimum and cannot be resized later, so leave room for datasets, checkpoints and outputs.
- Select at least one SSH key. Password login is disabled on GPU instances.
- Deploy. If the deployment fails to start, nothing is charged and the deposit is returned.
Step 2: open JupyterLab from the console
When the instance is running and the console offers it, open JupyterLab from the instance page. Two details matter:
- Sessions last 12 hours. After that, open JupyterLab again from the instance page. Your files and the running instance are not affected; only the browser session expires.
- Notebook traffic passes through Cloudj. That is convenient for editing and running cells, but it is not the right path for large uploads or downloads. Use SSH for big files.
Step 3: confirm PyTorch sees the GPU
In a new notebook, run:
import torch
print(torch.__version__)
print(torch.cuda.is_available())
print(torch.cuda.get_device_name(0))
x = torch.randn(4096, 4096, device="cuda")
print((x @ x).sum().item())If is_available() returns False, check the instance status and logs on the instance page first. You can also open a terminal in JupyterLab and run nvidia-smi to see the GPU, memory use and driver.
Install extra packages from a notebook cell with %pip install plus the package name, or from the JupyterLab terminal. Avoid reinstalling torch itself unless you need a specific build, because the template's version is matched to its CUDA libraries. The PyTorch installation page helps if you do need a different build.
Step 4: the SSH tunnel alternative
Some people prefer their local editor, or want JupyterLab without the 12-hour browser session. Connect with the SSH command from the Connection tab and start JupyterLab yourself:
ssh -L 8888:localhost:8888 -p <port> root@<host>
jupyter lab --no-browser --ip 127.0.0.1 --port 8888Run the first line on your laptop, then the second inside that SSH session (ideally within tmux). Open http://localhost:8888 locally and use the token JupyterLab prints. Editors with Jupyter support can connect to the same address. The SSH into a GPU instance guide covers keys, ports and the up-to-three-minute wait for a newly added key.
Step 5: move large files over SSH
Use rsync or scp for datasets and model weights, not the JupyterLab upload button:
rsync -avP -e "ssh -p <port>" ./data/ root@<host>:/workspace/data/
rsync -avP -e "ssh -p <port>" root@<host>:/workspace/outputs/ ./outputs/rsync resumes interrupted transfers and skips files that are already there. Bandwidth is charged per GB at the machine's listed price, so avoid moving the same data twice.
Step 6: keep notebooks backed up
Machines are independent hosts with no hardware SLA. Each machine also has an "available until" date, and when it arrives the instance and its disk are removed. Treat the instance disk as temporary:
- Commit notebooks and code to Git from the JupyterLab terminal, regularly.
- Copy checkpoints and outputs to your own storage as they are produced.
- Before you destroy the instance, do a final sync.
The guide to backing up before availability ends gives a full routine.
Step 7: stop or destroy
Stop keeps the disk and charges storage only, but releases the GPU; starting again may wait until a GPU is free. Destroy deletes the instance and its disk and stops charges. For most notebook work, saving everything and destroying is the cleaner habit. Live prices for every card are on GPU cloud.
FAQ
Is there a desktop or remote desktop with the template?
No. GPU instances have no graphical desktop. Use JupyterLab in the browser or SSH.
What happens after 12 hours in JupyterLab?
The browser session ends; open JupyterLab again from the instance page. The instance keeps running.
Can I use a different PyTorch version?
Yes, either by installing it in the instance or with a custom public Docker image at a higher account level.
Why use SSH for big files?
JupyterLab traffic passes through Cloudj and is meant for interactive work. SSH is direct and resumable with rsync.
Get started
Open the GPU deploy page, choose the PyTorch + JupyterLab template and a model that fits your work. Verify CUDA in the first cell, move big files over SSH, and commit your notebooks before you end the session.