Self-Hosted Reactive Notebooks: Marimo vs Livebook vs JupyterLite

Introduction

Notebooks have become the lingua franca of data science, exploratory programming, and technical documentation. But traditional notebooks like Jupyter suffer from a fundamental problem: hidden state. Cells execute in order, but the order you see on the page may not be the order they ran — leading to the infamous “works on my machine but not when I re-run from top” bug.

Reactive notebooks solve this problem by automatically tracking dependencies between cells and re-executing everything that depends on a changed cell. When you modify a variable or function, every cell that uses it updates automatically. This eliminates hidden state, makes notebooks reproducible by default, and fundamentally changes how you interact with code.

In this guide, we compare three leading self-hosted reactive notebook platforms: Marimo (Python), Livebook (Elixir), and JupyterLite (Python, WebAssembly). Each brings a unique philosophy to interactive computing.

Comparison Table

Marimo: Reactive Python Notebooks

Marimo is a next-generation reactive notebook for Python created by Akshay Agrawal and team. Unlike Jupyter notebooks where cells can be executed in any order, Marimo automatically builds a directed acyclic graph (DAG) of cell dependencies and re-executes affected cells when inputs change. This means your notebook’s outputs are always consistent with the code you see on screen — no more hidden state bugs.

Key Features:

• Automatic reactivity via dependency analysis
• SQL cells with built-in database connectors
• Interactive UI elements (sliders, dropdowns, date pickers, tables)
• Export to pure Python scripts or static HTML
• Git-friendly .py file format (not JSON)
• WASM-powered static export for sharing
• Built-in package management with micropip

Self-Hosting with Docker:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

version: "3.8"
services:
  marimo:
    image: marimo/marimo:latest
    container_name: marimo
    ports:
      - "2718:2718"
    volumes:
      - ./notebooks:/notebooks
    environment:
      - MARIMO_SKIP_UPDATE_CHECK=1
    command: marimo edit --host 0.0.0.0 --port 2718 --no-token /notebooks
    restart: unless-stopped

For production deployment with authentication:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

version: "3.8"
services:
  marimo:
    image: marimo/marimo:latest
    container_name: marimo
    ports:
      - "2718:2718"
    volumes:
      - ./notebooks:/notebooks
    command: >
      marimo run --host 0.0.0.0 --port 2718
      --token ${MARIMO_TOKEN}
      /notebooks/main.py
    environment:
      - MARIMO_TOKEN=${MARIMO_TOKEN}
    restart: unless-stopped

Marimo notebooks are stored as plain .py files, making them fully compatible with version control systems. You can run a notebook as a standalone web app with marimo run notebook.py, or edit it interactively with marimo edit. The reactive model ensures that every time you open a notebook, running all cells from top to bottom produces identical results — no more debugging execution order issues.

Example reactive notebook pattern:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# Cell 1: Parameter (changing this re-executes cell 2)
import marimo as mo
rate = mo.ui.slider(0, 100, value=5, label="Interest Rate %")
rate

# Cell 2: Computation (depends on cell 1)
principal = 10000
years = 10
final = principal * (1 + rate.value / 100) ** years
mo.md(f"After {years} years: **${final:,.2f}**")

Livebook: Elixir’s Interactive Powerhouse

Livebook is Elixir’s answer to computational notebooks, created by the Dashbit team behind the Elixir programming language. Built on the Erlang VM (BEAM), Livebook offers unique capabilities: real-time collaboration, fault tolerance (if a cell crashes, it doesn’t take down the whole notebook), and access to Elixir’s entire ecosystem of concurrent, distributed computing libraries.

Key Features:

• Real-time multiplayer collaboration
• Process isolation (crashes don’t affect other cells)
• Rich Kino ecosystem for UI widgets, charts, databases
• Built-in secret management for API keys
• Smart cell templates for common tasks
• Livebook Hub for discovering and sharing notebooks
• Scheduling and automation capabilities

Self-Hosting with Docker:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

version: "3.8"
services:
  livebook:
    image: ghcr.io/livebook-dev/livebook:latest
    container_name: livebook
    ports:
      - "8080:8080"
    volumes:
      - ./livebook-data:/data
    environment:
      - LIVEBOOK_PASSWORD=${LIVEBOOK_PASSWORD}
      - LIVEBOOK_DATA_PATH=/data
      - LIVEBOOK_HOME=/data
      - LIVEBOOK_ROOT_PATH=/data/notebooks
      - LIVEBOOK_PORT=8080
    restart: unless-stopped

Livebook’s real-time collaboration is a standout feature — multiple users can edit the same notebook simultaneously with cursors and changes visible in real time. Smart cells provide templated workflows for common tasks like database queries, HTTP requests, chart generation, and machine learning model training. The Kino ecosystem is extensive and well-maintained.

JupyterLite: Jupyter in the Browser, Zero Server Required

JupyterLite is a WebAssembly-powered distribution of JupyterLab that runs entirely in the browser. Built on Pyodide (Python compiled to WebAssembly) and JupyterLab components, JupyterLite requires no server-side Python process — deploy static files to any web server and users get a full JupyterLab environment with zero installation. It’s the easiest option to deploy and the most familiar interface for existing Jupyter users.

Key Features:

• Full JupyterLab interface in the browser
• Python kernel via Pyodide (WebAssembly)
• Pre-installed scientific Python packages (NumPy, Pandas, Matplotlib)
• Zero server-side compute required
• Custom extensions and kernels support
• Terminal emulator in the browser
• File system access via IndexedDB

Self-Hosting with Docker:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

version: "3.8"
services:
  jupyterlite:
    image: nginx:alpine
    container_name: jupyterlite
    ports:
      - "8080:80"
    volumes:
      - ./jupyterlite-dist:/usr/share/nginx/html:ro
    restart: unless-stopped

Build your JupyterLite distribution with custom packages:

1
2
3
4
5
6
7
8

# Install JupyterLite builder
pip install jupyterlite

# Build with extra packages
jupyter lite build --contents ./notebooks --XeusPythonEnv.packages=plotly,scikit-learn

# Deploy the _output directory to your web server
cp -r _output/* /opt/jupyterlite-dist/

JupyterLite’s primary advantage is its deployment simplicity — no application server, no database, no runtime dependencies beyond a web server. However, it uses traditional notebook semantics (no automatic reactivity), and Pyodide’s package ecosystem, while extensive, doesn’t cover every PyPI package (especially those with C extensions). It works best as a lightweight Jupyter-compatible environment rather than a full replacement.

Why Self-Host Your Reactive Notebooks?

Cloud notebook platforms like Deepnote, Hex, and Google Colab offer convenience but come with significant trade-offs. Your data, code, and computational patterns live on their infrastructure — subject to their pricing changes, feature deprecations, and data access policies. Self-hosting gives you complete ownership of both the computing environment and the data processed within it.

For data science teams working with proprietary datasets, self-hosting is often a compliance requirement. Healthcare data, financial models, and customer analytics can’t leave your infrastructure. Self-hosted notebooks keep all computation on your servers while still providing the interactive, collaborative experience teams need. You can integrate with your existing authentication systems (LDAP, OAuth, SAML) and audit logging infrastructure.

Cost is another factor. Cloud notebook platforms charge per compute hour or seat — a 10-person data team can easily spend $500-2,000/month on hosted notebook services. Self-hosted notebooks run on your existing infrastructure with predictable costs. A single server with 8GB RAM can comfortably handle a small team’s notebook usage.

For related self-hosted development tools, see our traditional notebook comparison guide and self-hosted API documentation platforms. If you’re building out a development environment, check our JupyterHub multi-user guide for enterprise-scale deployments.

FAQ

How is reactivity different from Jupyter’s cell-by-cell execution?

In traditional Jupyter, cells execute in the order you run them, which may differ from their visual order on the page. This creates hidden state — a variable assigned in cell 10 might be used in cell 5 if you ran them out of order. Reactive notebooks build a dependency graph and automatically re-execute all cells that depend on a changed input. The visual order always matches the execution order, eliminating hidden state entirely.

Can I migrate existing Jupyter notebooks to Marimo?

Yes, Marimo provides a conversion tool (marimo convert notebook.ipynb) that transforms Jupyter notebooks into Marimo’s reactive format. The converter analyzes cell dependencies and restructures the notebook accordingly. However, notebooks with complex side effects or global state manipulation may require manual adjustments. Start with smaller notebooks and verify correctness after conversion.

Does Livebook only work with Elixir?

Livebook’s native execution environment is Elixir/Erlang, but it can connect to other language runtimes through its Kino ecosystem. You can attach Python, R, and JavaScript environments as “smart cells” that execute code in separate processes. For polyglot teams, this means you can use Livebook as the notebook interface while running Python or R code through attached kernels.

How do I handle secrets and API keys securely?

Marimo supports environment variables and .env files. Livebook has a built-in secrets management system (Hub Secrets) that stores credentials encrypted and injects them at runtime without exposing them in the notebook source. JupyterLite runs client-side only, so secrets should not be embedded in notebooks — use it for public or pre-processed data only.

What’s the resource footprint for self-hosting these notebooks?

Marimo uses 200-500MB RAM per active user, scaling linearly with data size. Livebook uses ~200MB baseline plus ~100MB per collaborative session. JupyterLite is static files with zero server-side compute — resource usage is entirely client-side. For 10 concurrent users, a 4GB RAM server comfortably runs Marimo or Livebook. JupyterLite scales to thousands of users on a $5/month static hosting plan.

Can I schedule notebooks to run automatically?

Yes. Marimo supports marimo run notebook.py as a CLI command that you can schedule via cron. Livebook’s Kino ecosystem includes process scheduling with Kino.Process for recurring execution. JupyterLite is static and doesn’t support server-side scheduling — but you can use the standard Jupyter ecosystem tools (papermill, cron) with a JupyterHub instance instead.

💰 想测试你的市场判断力？我用 Polymarket 做预测市场交易——这是全球最大的预测市场平台，从大选结果到技术监管时间线，什么都可以押注。和赌博不同，这是真正的信息市场：你懂的信息越多，胜率越高。我靠预测技术相关事件的走向已经赚了不少。用我的邀请链接注册：Polymarket.com