Run DataSpell Notebooks on a Remote GPU via SSH Interpreter

Use the remote host for compute, keep the IDE local

When a notebook needs GPU, large data, or a locked-down lab environment, run the kernel on that server and edit locally. In DataSpell the practical way is to bind the notebook to an SSH interpreter. The IDE connects over SSH, starts or attaches to a Jupyter kernel on the host, and renders outputs, plots and the variable viewer locally while completions and inspections use the remote environment's packages.

Reserve the managed local server for quick exploration. Switch to an SSH interpreter for anything GPU-bound, data-heavy, or requiring a specific cluster environment. Keep reproducibility with an environment.yml or requirements file committed alongside the notebooks.

How the remote interpreter works

DataSpell reuses your SSH configuration for host, port, key or credential. It places the notebook files in a remote working/sync directory, launches Jupyter on the host, and tunnels the connection back. Cell execution happens on the remote Python interpreter, not your laptop. The IDE shows remote paths in the file tree and syncs edits between local and remote working directories.

Completion, type hints and inspections are resolved against the remote interpreter's installed packages, so you see accurate suggestions for libraries that exist only on the server.

Worked configuration

Open the notebook and open the Jupyter server/interpreter picker. Choose an SSH interpreter rather than a configured-server URL. A configured-server URL assumes you already run Jupyter yourself; an SSH interpreter lets DataSpell manage the server for you.

Provide the SSH connection details the IDE can reuse, then select the Python environment on the host. Example target: /opt/conda/envs/ml/bin/python on the training server. Set a remote working/sync directory such as /home/user/work that mirrors your local project folder.

With the interpreter selected, a diagnostic cell can confirm where execution runs:

import socket, platform; print(socket.gethostname()); print(platform.node()); # import torch; # print(torch.cuda.is_available())

The hostname and node should match the remote host, and any GPU check reflects the remote machine's hardware, not your laptop's. Do not hard-code absolute local paths in cells; use paths relative to the remote working directory.

Permissions needed: SSH access to the host with permission to launch processes, and write access to the remote working directory. Risks include exposing credentials if you store them in notebooks, and network interruptions that drop the kernel.

Limits

• Kernel state is lost on network interruptions. Cells must be re-run after reconnect.
• Large data transfers over the tunnel are slow. Keep heavy datasets on the remote host and reference them by remote path.
• The remote environment must already contain required libraries. DataSpell does not silently clone your local conda environment.
• Remote paths differ from local ones. Relative imports and file opens can break if code assumes a local filesystem layout.

Common mistakes

• Picking a base interpreter that lacks notebook dependencies. The interpreter must be able to start a Jupyter kernel.
• Expecting local edits to data files to appear remotely before sync. Changes are synced via the configured working directory; verify sync status in the IDE.
• Hard-coding local absolute paths in cells. Use paths relative to the remote working directory or construct them from a configurable root.
• Confusing a configured-server URL with an SSH interpreter. With a URL you manage Jupyter yourself; with SSH interpreter DataSpell manages launch and tunneling.
• Storing secrets in notebooks or printing them in cell outputs. Outputs are saved with the notebook file.

Practical check

After connecting, run a cell that prints socket.gethostname() and, if applicable, a GPU availability check. The result should reflect the remote host. Review the in-IDE help or JetBrains DataSpell documentation for your installed version to confirm exact dialog fields, as UI names vary between releases. JetBrains has been consolidating Python and notebook tooling, so product naming and packaging may change.