Livebook: Interactive Elixir Notebooks You Can Run Anywhere

What Livebook Is and Who It Serves

Livebook is a web application for writing interactive and collaborative code notebooks, with Elixir as the execution language. The README describes it as a tool for evaluating Elixir code on demand in code cells alongside Markdown. The audience is narrower than the notebook category as a whole: people already working in Elixir, or people who want to introspect and document an existing Elixir project. The README states that Livebook can connect to an existing node or run inside an existing Elixir project with access to all of its modules and dependencies, and calls this a good fit for introspecting and documenting existing projects. That is the specific problem: most notebook tools treat the host language as a guest runtime, while Livebook treats an Elixir project as the thing being explored. If your work is Python data science, Livebook is not the tool for you. If your work is an Elixir service with a supervision tree you want to poke at interactively, the fit is direct.

How Notebooks, Cells and Runtimes Fit Together

The mechanism has three visible parts. First, notebooks are stored in the .livemd format, which the README describes as a subset of Markdown with support for Mermaid diagrams and KaTeX formulas. Because it is plain Markdown, it plays well with version control and can be shared as a file rather than as an opaque database record. Second, execution happens in code cells evaluated on demand, with a CodeMirror editor providing autocompletion, inline documentation and formatting. Third, execution targets a runtime: a fresh Elixir instance, an existing node, or an existing Elixir project. The README also describes state tracking: Livebook ensures code runs in a predictable order, tracks notebook state, and annotates which parts are stale. That staleness annotation is the part worth pausing on. In a notebook where cells can be reordered, knowing which results no longer reflect current code is the difference between a document you trust and one you re-run from the top every time. Collaboration is handled without additional setup according to the README, meaning multiple users can work on the same notebook at once. Interactive output comes through Kino, which the README lists as the path to Vega-Lite charts, tables and maps. Smart cells sit above that: the README describes them as UI-driven actions for querying databases, plotting charts and building maps without writing the underlying code by hand.

Installing Livebook and Running a First Notebook

The README points to the Install section of livebook.dev and lists several routes: a desktop installer for Mac and Windows, an AppImage for Linux, Docker images, and direct installation with Elixir. Docker is the shortest path if you do not have Elixir on the machine. This command starts Livebook with the default configuration and publishes the two ports the README shows:

docker run -p 8080:8080 -p 8081:8081 --pull always ghcr.io/livebook-dev/livebook

Port 8080 serves the application and 8081 is the iframe port. To keep notebooks on your own disk, the README gives a variant that mounts the current directory at /data and passes your user ID so created files get proper permissions:

docker run -p 8080:8080 -p 8081:8081 --pull always -u $(id -u):$(id -g) -v $(pwd):/data ghcr.io/livebook-dev/livebook

If you expose Livebook beyond localhost, the README shows setting a password through an environment variable:

docker run -p 8080:8080 -p 8081:8081 --pull always -e LIVEBOOK_PASSWORD="securesecret" ghcr.io/livebook-dev/livebook

To move the ports, the README pairs LIVEBOOK_PORT and LIVEBOOK_IFRAME_PORT:

docker run -p 8090:8090 -p 8091:8091 --pull always -e LIVEBOOK_PORT=8090 -e LIVEBOOK_IFRAME_PORT=8091 ghcr.io/livebook-dev/livebook

Once it is up, the README says to visit the Learn section, which holds introductory guides including Welcome to Livebook. That guide is where a new user should start before writing anything. For direct installation the README states you need Elixir v1.18 or later, plus the Erlang applications inets, os_mon, runtime_tools, ssl and xmerl, which some package managers split out. On Ubuntu the README gives this:

sudo apt install erlang-inets erlang-os-mon erlang-runtime-tools erlang-ssl erlang-xmerl erlang-dev erlang-parsetools

One caveat the README states plainly: the livebook package on Hex is meant to be used as a CLI tool, and Livebook is not officially supported as a Mix or Hex dependency. Do not add it to your mix.exs deps expecting a library.

Where Livebook Gets Awkward

The runtime model is the main constraint. Livebook executes Elixir, and the README's integrations page covers languages and data sources that work out of the box, but the notebook itself is an Elixir surface. Teams with mixed Python and Elixir work will end up running two notebook tools rather than one. The packaging note is a second limitation: because the livebook package is positioned as a CLI tool and not a supported Mix dependency, you cannot treat Livebook as an embedded library inside an application the way you might embed a reporting engine. It runs as an application you visit, not as a module you call. Third, the README does not document a built-in multi-user account system with roles or per-notebook access control. It documents a password environment variable for the whole instance and describes collaboration as multiple users on the same notebook without additional setup. That is fine for a trusted team on a private network. It is not a hosted notebook platform, and anyone expecting per-user isolation should look at the deployment documentation before assuming it exists. Finally, the README does not document rollback or notebook history beyond what version control gives you through .livemd files, so recovery depends on your Git habits rather than on the application.

Livebook Against Jupyter and VS Code Notebooks

The natural comparison is Jupyter. Jupyter's architecture is kernel-based: a notebook document talks to a kernel process, and kernels exist for many languages, with Python as the reference implementation. Livebook's architecture is Elixir-native: the notebook runs Elixir, and the interesting capability is connecting that execution to a live node or an existing project rather than to a generic kernel. If you need a Python kernel, Jupyter is the answer and Livebook is not competing there. If you need to attach a notebook to a running Elixir system and inspect its modules and dependencies, Jupyter has no equivalent out of the box. The second comparison is editor-integrated notebooks, such as the notebook support in VS Code. Those keep you inside an editor you already use and inherit its file handling, but they do not provide Livebook's Smart cells or its Kino-based interactive outputs, and they do not have the same notion of connecting to a running Elixir node. The trade is convenience of a familiar editor against a purpose-built Elixir runtime and output layer.

Maintenance, Releases and Licence

The repository is not archived, and the last push was on 2026-09-17. Releases are frequent: v0.19.10 was published on 2026-09-18, following v0.19.9 on 2026-08-05. There is also a nightly channel, with a nightly build published on 2024-10-25 and a nightly container image referenced in the README. That combination matters for upgrade planning. If you track stable releases, you are pulling from a version stream that moves on a scale of weeks, and the CHANGELOG.md at the repository root is where the changes are recorded. If you track nightly, you are opting into main-branch features, and the README presents that image as the way to try features from the main branch. The licence is Apache-2.0, which is a permissive licence with an explicit patent grant. That is a reasonable default for internal and commercial use, but licence terms interact with how you distribute modified builds, and that is a question for your own legal review rather than something to settle from a README. Note also that the desktop installers and container images are distribution artifacts of the same project, so the licence question does not change by install method.

Editorial conclusion

Adopt Livebook if you work in Elixir and want notebooks that live in Git as .livemd files, connect to existing Mix projects, and support multiple editors in one session. Do not adopt it if your work is Python or R centric and you need the Jupyter ecosystem's kernel breadth, or if you need a hosted multi-tenant notebook service, which Livebook does not provide. Before committing, verify that your Elixir version is v1.18 or later, that the Erlang applications inets, os_mon, runtime_tools, ssl and xmerl are present, and that your deployment path (desktop installer, Docker image, or escript) meets your authentication needs.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. livebook-dev/livebook on GitHub
3. Project website
4. README
5. Releases