JupyterLab

Launch this template and a JupyterLab server is waiting at your instance URL, with CUDA and PyTorch already installed and the GPU visible from the first cell.

The image is grafilab/jupyterlab:2026-06-09, built on the Jupyter project’s own quay.io/jupyter/pytorch-notebook:cuda12-latest and adjusted to run as root so the platform’s SSH provisioning works.

• JupyterLab on port 80, published at https://<your-slug>.instance.grafilab.ai.
• PyTorch with CUDA, plus the usual scientific Python stack from the upstream notebook image.
• A root shell over SSH on the same container, for anything the notebook interface is awkward for.

Pick it for exploratory work: trying a model, cleaning a dataset, running a fine-tune you want to watch cell by cell. For long unattended training runs, PyTorch + CUDA with tmux is the better shape.

Deploy an instance and pick JupyterLab in step 2, Template Selection. Any GPU card works; match the VRAM to the model you intend to load. The full walkthrough is in Deploy a GPU Instance.

1. In the console open My Instance and wait until the card reads Active.

2. Open https://<your-slug>.instance.grafilab.ai. The slug is the three-word name on the instance card.

3. In the launcher, click the Python 3 notebook tile. An empty notebook opens.

Run this in the first cell:

import torch

print(torch.__version__)
print(torch.cuda.is_available())
print(torch.cuda.get_device_name(0))

You should see True and the name of the card you rented. For the driver’s own view, run a shell command from a cell:

!nvidia-smi

If torch.cuda.is_available() prints False, confirm you rented a GPU node rather than a CPU-only one, and check that the instance card shows a GPU and VRAM.

Install from a cell with !pip install, or from an SSH shell with plain pip install:

!pip install transformers accelerate

Restart the kernel afterwards (Kernel → Restart Kernel) so the new package is importable. Everything you install lives in the container and disappears with the rental, so keep a requirements.txt in your project rather than reconstructing the environment from memory next time.

scp -P <port> ./dataset.zip <your-slug>@<ssh-proxy-host>:/root/
rsync -avP -e "ssh -p <port>" ./project/ <your-slug>@<ssh-proxy-host>:/root/project/

wget https://example.com/dataset.tar.gz
huggingface-cli download <repo-id> --local-dir ./data

The pragmatic option is to treat the instance URL as a secret: don’t post it, don’t put it in a shared doc, and end the rental when you are done.

If you need a real lock, JupyterLab reads a token from the JUPYTER_TOKEN environment variable — with one set, the URL only works when the token is appended or entered. Setting it means restarting the server with that variable in its environment, which you do over SSH.

Notebooks are cheap to lose only if they live somewhere else. Push to git as you go, or use Backup on the instance card to archive your working directory before Expire at.