Analytics

A notebook server,already running

JupyterLab on Miniconda, served straight to the browser.No desktop and no VNC — the notebook is the page.

JupyterLab 4.6.34 cores · 8 GBServed on 8888
hub://jupyter

$ dxflow workflow create --identity jupyter hub://jupyter --start --link

01Pick a machinecores, memory and a rate per hour
02Create the workflowpulled from the hub, once
03Run it, then stopstopped when the work is done
The application

Notebooks, codeand the data beside them

JupyterLab on top of Miniconda, with conda and pip already there.

Notebooks and terminals

Cells, a file browser and a terminal, all inside the single page.

conda and pip

Miniconda sits on the PATH, so add numpy or pandas when you need.

It opens on your work

WORKING_DIR points at a folder under /volume, and it opens there.

How you run it

Two variables,and the rest is the notebook

There is a password and a folder. Everything else you do from inside the page.

PASSWORDThe sign-in page checks this. It ships as dxflow, and everyone reading this knows that.
WORKING_DIRA path under /volume to open in. Leave it empty and you land at the top of the volume.
start it your way

$ dxflow workflow start jupyter --override env.app.PASSWORD=something-long

$ dxflow workflow start jupyter --override env.app.WORKING_DIR=projects/analysis --link

The session

One port,and a sign-in page

The token is disabled, so the password is the only way in.

8888WebJupyterLab itself
/volumeStoragenotebooks and data
Open it from anywhereStart with --link and the page comes back on an HTTPS address.
Set a password firstPASSWORD defaults to dxflow, and everyone can read this page.
Good to know

Miniconda is alreadyon the PATH

The image is JupyterLab standing on a conda install, so the libraries you need are one terminal away.

Add what you need

conda and pip both work from a notebook terminal. numpy, pandas, scikit-learn or a lab extension, installed where the volume keeps them.

The token is off

There is no token in the URL to fall back on. The password is the only way in, which is why a real one matters.

Everything lives on the volume

Notebooks, data and the environment you built are under /volume, and they are there at the next start.

The image

Pulled once,then it stays

Jupyter Lab arrives as one image. This is what comes down the first time, and what the disk should have free for it.

368Mamd64compressed, the way the registry counts it
367Marm64compressed, the way the registry counts it
50GOn diskunpacked, with room to work beside it
ghcr.io/dxflow-ai/jupyter:latestPublished from the hub, pulled on the first start and kept for the ones after it.
Either architectureamd64 and arm64 are both published, and the machine pulls the one it runs.
What it asks for

What it wants,is what it needs

The definition asks for 4 cores and 8 GB, and the image wants all of it. A start given --fit still caps each step to whatever the machine actually has.

4 cores · 8 GBAsks forwhat the definition writes down
4 cores · 8 GBRuns onthe same figure, with nothing spare
Not neededGPUit works on the cores alone
The ask is the floorThe definition and the image agree on this one, so a smaller machine has nothing left to trim.
--fit caps it to the hostA start given --fit trims each step to what the machine actually has, for that start alone. The definition is never rewritten.

Machines that fit it

Jupyter Lab asks for 4 cores and 8 GB. Cheapest first.

E2 Standard-4
$0.168/ hour4 cores · 16 GBStart this machine
T4g XLarge
$0.168/ hour4 cores · 16 GBStart this machine
C7g XLarge
$0.181/ hour4 cores · 8 GBStart this machine
Run Jupyter Lab on your own machinePick a machine that meets it, and it opens about a minute after you ask.