Marimo is an open-source reactive Python notebook where every notebook is stored as a plain .py file, and cells automatically re-run when the values they depend on change — like cells in a spreadsheet. If you have ever shipped a notebook that only worked because you happened to run the cells in the right order, or fought a git diff that was 400 lines of unreadable JSON, that one sentence is the reason to keep reading.

What it is#

Marimo (marimo.io, marimo-team/marimo on GitHub) is a notebook environment for Python, positioned as a replacement for Jupyter rather than a plugin on top of it. It is licensed under Apache-2.0 and is free to use and self-host.

The core idea is a reactive dataflow graph. Marimo parses your cells, figures out which variables each cell reads and writes, and builds a dependency graph. Change a variable in one cell and every downstream cell re-runs (or is marked stale) so the outputs on screen always match the code. There is no "Run All from the top and pray" ritual, because the runtime enforces consistency for you.

The second pillar is storage. A Marimo notebook is a real Python module — importable, flake8-able, diffable — not a JSON blob with embedded outputs and execution counts. That single decision is what makes the rest (version control, running as a script, code review) fall into place.

Why it's different (the two things that matter)#

1. It's stored as a .py file. Jupyter's .ipynb format is JSON that interleaves code, output, and metadata. Git can technically track it, but diffs are noise, merges are painful, and code review is a chore nobody enjoys. Marimo notebooks are plain Python, so git diff shows exactly the lines you changed, pull requests read normally, and your linters and formatters just work.

2. It's reactive, so hidden-state bugs die. In Jupyter, the notebook you see and the kernel's actual memory can silently disagree. You edit a cell, forget to re-run a downstream one, and now a variable holds a stale value that exists nowhere in your code. This is the entire "works on my machine because I ran the cells out of order" class of bug. Marimo eliminates it by construction: the dependency graph guarantees that what you see is what the code produces, top to bottom, every time. It also forbids defining the same variable in two cells, which stops a whole other family of spooky action at a distance.

Reactivity isn't a convenience feature — it's a correctness guarantee that turns "it ran for me" into "it runs, period."

Everything builders actually want downstream — reproducibility, clean version control, shipping a notebook as an app — follows from these two choices. The honest side-by-side is in the table at the top of this page.

Who it's for#

Marimo is for people who treat notebooks as software, not scratch paper. That means data scientists and ML/AI engineers who need experiments to reproduce, teams who want notebook changes to survive code review, and solo founders who prototype in a notebook and then want to ship it as an internal tool or a public demo without a rewrite. Because a notebook can double as a script and as a web app, it's especially good when the same artifact needs to be a dashboard, a batch job, and a reproducible record all at once. If you never version-control your notebooks and never hand them to anyone else, Jupyter's inertia may be fine — the payoff here scales with how much your notebooks matter to other people (or to future you).

How to start#

Install it with pip or uv, open the editor, and you're in a reactive notebook. The same file runs as an app or exports to a shareable artifact.

# install (pip or uv)
pip install marimo
uv add marimo

# open the interactive editor (creates/edits a .py notebook)
marimo edit notebook.py

# serve the notebook as a read-only interactive web app
marimo run notebook.py

# export to a static/WASM HTML artifact
marimo export html-wasm notebook.py -o app.html

# bring an existing Jupyter notebook over
marimo convert old_notebook.ipynb > new_notebook.py

Pricing#

The Marimo notebook is open source under Apache-2.0: free to use, free to self-host, no seat limits. If you'd rather not manage infrastructure, the team offers molab, a cloud-hosted Marimo workspace (think Colab-style), which is currently free to use during its public preview, including access to GPU-backed compute. Marimo also publishes an enterprise-facing page for organizations that want managed deployment; specifics there aren't publicly priced, so evaluate it directly rather than taking a number on faith. For the vast majority of individual builders, the free open-source tool is the whole story.

When to stick with Jupyter#

Be honest about the tradeoff: Jupyter's moat is its ubiquity. Its ecosystem of extensions, kernels beyond Python, tutorials, and Stack Overflow answers is vast and battle-tested, and every hosting platform, course, and collaborator already assumes .ipynb. If you live inside JupyterLab extensions, need non-Python kernels, or are handing notebooks to an audience that expects the standard format, the switching cost may outweigh the wins. Marimo's reactivity also changes how you write cells — a nonlinear, click-anywhere Jupyter workflow needs a small mental adjustment. Marimo is the better default when reproducibility, version control, and shipping matter; Jupyter is the safer call when ecosystem breadth and universal familiarity matter more.