Go to Valohai AppBook a Demo

Manage Notebook Lifecycle

You can run Valohai Notebooks on cloud machines, not "always ready" serverless containers. This design keeps your costs down when you're not actively working, but it means notebooks take time to start.

Why Notebooks Take Time to Start

When you launch a notebook, Valohai provisions a fresh machine in your infrastructure. This involves:

  1. Spinning up a new VM or container

  2. Pulling your Docker image

  3. Installing Jupyter (if not in the image)

  4. Downloading input files from cloud storage

Expect 2–5 minutes depending on:

  • Your environment type (cloud auto-scale, Kubernetes, on-premise)

  • Docker image size

  • Input file sizes

  • Current resource availability

This is a cold start. We don't keep machines hot between sessions because you'd pay for idle time.

Stopping Your Notebook

When you stop a notebook:

  1. Valohai saves the final notebook state

  2. All outputs in /valohai/outputs/ are versioned

  3. The machine is released and scale down if there are no other executions in the queue

  4. Billing stops once the machine is scaled down

You must manually stop notebooks. They don't time out automatically.

How to Stop

From the Valohai UI:

  1. Go to the Notebooks tab in your project

  2. Find your running notebook

  3. Click Stop

The notebook execution moves to "Stopped" status. Your work is preserved and versioned—you can view the final .ipynb file and any outputs you saved.

⚠️ Critical: Notebooks left running cost the same as active training jobs, even if you're not using them. Always stop notebooks when done.

Keeping a Machine Warm

If you need instant access and don't want to wait for cold starts, you can keep a notebook running between work sessions.

This means:

  • Zero startup time when you return

  • Your environment and installed packages persist

  • You pay for the machine continuously, even when idle

When to Consider This

Keeping a machine warm makes sense if:

  • You're actively iterating and need to switch in/out frequently

  • The cost of idle time is less than the cost of your time waiting for restarts

  • You're debugging time-sensitive issues

For most experimentation workflows, cold starts are the better choice.

Next Steps

PreviousConvert to Production ScriptNextTroubleshooting

Last updated

Was this helpful?