While Colaboratory is built on top of Jupyter Nextjournal is not.
We do support importing Jupyter notebooks and running Jupyter kernels, we also have our own runtime protocol.
In Jupyter (and hence in Colaboratory) you normally have one runtime that's running both your server code as well as the user code. In Nextjournal there's a separate application called the Runner that's orchestrating the runtimes which currently are docker images.
This allows us to use Nextjournal notebooks to do any kind of installations without the need for a full Jupyter kernel inside the image, something that gets tricky in Jupyter. Once we have a bash shell inside the image, we can do installations.
You can choose to commit the filesystem state at any time as a docker image and reuse it in other notebooks. This is actually how our default environment images are built:
Our default Python environment https://nextjournal.com/nextjournal/python-environment is built on top of the minimal bash environment https://nextjournal.com/nextjournal/bash-environment which is importing just a stock ubuntu image.
Our system takes care of only referencing the image sha's everywhere, so everything is immutable and you can't accidentally overwrite anything.
You can also pull those docker images and use them locally.
Any data you upload or results you save (just write to a /results folder) is put into content-addressed storage, so same thing here, you'll never accidentally overwrite a file.
Lastly the document is stored in the database (Datomic) and you can restore any previous state.
Leveraging immutability at all layers of the stack is what enables our "remix" feature, so the ability to quickly and cheaply clone any published notebook and continue where another person left off.