# Jupyter on Runpod: where to save notebooks and results

Save Runpod Jupyter notebooks and outputs on the intended disk, distinguish kernel memory from files and verify an exported project in a clean session.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/runpod-jupyter-files-persistence/
Language: en

To retain Jupyter work on Runpod, save notebooks and outputs on the intended storage and verify a separate export. A volume disk survives Stop but not Terminate. An open browser tab and Python objects in kernel memory do not substitute for files written to a suitable resource.

## Separate three kinds of state

A session contains notebook code, disk files and the live kernel's variables. Saving the notebook records the document, not an independent copy of all process memory. After a kernel restart, required objects must be loaded or created again.

Map original inputs, edited data and results to specific directories. Runpod storage type determines what happens when the Pod stops or is deleted. Even `/workspace` must be checked because it may represent a local volume disk or an independent network volume.

## Find where relative paths write

Create a small file from a notebook cell, find its absolute path and locate it through a terminal or file interface. The directory used by the running notebook can differ from the project folder you expected.

Keep a clear project root and save its configuration. Do not depend on a manual directory change in a previous terminal. Include exports created elsewhere: a chart, CSV or downloaded archive can otherwise remain outside the folder chosen for backup.

## Preserve the irreplaceable parts

Consider a researcher correcting text labels and producing a metrics table. Public source data may be downloadable again; edited labels are a separate result and need preservation before the Pod ends.

| Object | Useful preservation check |
| --- | --- |
| Notebook | Save it and open an exported copy |
| Edited labels | Write a version with an identifiable date |
| Metrics | Export a readable result format |
| Kernel variables | Save the required artifacts explicitly |
| Temporary cache | Document how to download it again |

Try the notebook in a clean kernel at least through data loading. A hidden variable created in a deleted cell is a reproducibility problem even if the original session still answers correctly.

## Verify export and the next session

Use a transfer method supported by your connection. Check counts, sizes or checksums and open representative files outside the source Pod. A completed download indicator does not prove the project is usable.

Inspect cells, outputs and configuration for accidentally embedded tokens before sharing. Save required environment-variable names without secret values. The next session should use a known image, dependencies, inputs and execution order, rather than relying on a still-open tab or a former user's interactive state.

## Turn the check into a practical next step

An open notebook tab is not proof of saved work. Verify the path, backing storage, exported files and the ability to run from a clean kernel.

For the documented details, consult the [primary documentation](https://docs.runpod.io/pods/storage/types); [configuration reference](https://docs.runpod.io/pods/storage/transfer-files). Continue with [runpod network volume persistence](/journal/runpod-network-volume-persistence/) and [runpod http port proxy](/journal/runpod-http-port-proxy/).