How to backup JupyterLab?

I have JupyterLab running on a Mac laptop. I launch it from Anaconda Navigator. The server runs on the laptop. At the moment I have only a single workspace.

How would I recover the workspace on a new computer, or on the same computer if Apple has replaced the CPU and SSD volume under AppleCare because one day it refused to switch on?

All the documents relevant to the workspace should be under a single directory, is it enough to have a copy of that directory tree and also $HOME/.jupyter? Is there a way to make a convenient package that I can import into a new installation if needed?

I’m puzzled that I can’t seem to find anything relevant using the appropriate search terms, for example I get no results when I search for “backup” in the JupyterLab documentation. I see other threads about backups for JupyterHub but I don’t think those are relevant to my question. If this is already answered please point me in the right direction.


The .pynb files you can backup on GitHub (example here).
For the python environment, you can write a requirements.txt file, the easiest way to generate this would be by writing pip freeze > requirements.txt in the terminal.
You can then run pip install -r requirements.txt anytime you want to have that exact environment again.

There is also a way to make a backup of a whole anaconda environment:

But writing a single requirements.txt is the easiest way I’d say.

1 Like

Various jupyter tools look for/put their internal state in a number of places. You can see them all with:

jupyter --paths

For the most part, aside from your files (which you’d back up by “normal means” with e.g. TimeMachine or CrashPlan or cron jobs) stock jupyterlab only writes files out for workspaces (snapshots of your open dock panel tabs, sidebar status, etc.) and settings. For me, on a Linux box, these are in:


single requirements.txt is the easiest way I’d say.

Welp, if you’re on OSX in 2023… pip is still not going to be your best friend on Apple Silicon.

If you’re already on the conda bus, getting an almost perfect copy of an environment is fairly easy:

conda list -n <path to environment> --explicit > this-old-env.txt

Which can rebuilt later with:

conda create -n this-new-env --file this-old-env.txt

Unfortunately, if you go to a different processor architecture, this won’t work anymore, as that lock file captures binary packages. For this reason, and various other ones, I recommend capturing both your conda and pip packages as portably-as-possible, while preserving your intent, in a single environment.yml and backing that up:

- conda-forge
- jupyterlab >=3.6,<4
- python >=3.10,<3.11
- pip
- pip:
  - not-appearing-in-conda-forge

Instead of ever using conda install and pip install, add things to that file, and conda env update. Or, better still, adopt mamba, which can sometimes be an order of magnitude faster at solving. This is a lot easier to reason about, over time, especially if that file is stored it such a way that you can look at the changes (e.g. git or TimeMachine). Of course, you can still use mamba list --explict after doing the mamba env update.