nannou: a Rust creative-coding framework built on Bevy

What nannou solves, and who it is actually for

nannou is a creative-coding toolkit for Rust. The README frames the goal plainly: making it easy for artists to express themselves with simple, fast, reliable, portable code, whether the work is a twelve-month installation or a five-minute sketch. The project was started because its authors wanted a framework in the spirit of Processing, OpenFrameworks and Cinder, but for Rust.

That sentence defines the audience precisely. This is not a tool for someone who has never programmed. Rust's ownership rules, cargo and the borrow checker sit between the artist and the canvas, and no amount of API design removes them. What nannou offers in exchange is a sketch loop and a drawing interface that feel much closer to Processing than to raw windowing and GPU code, while the underlying language gives you deterministic performance and a single static binary to ship.

The scope is wider than drawing. The repository ships separate crates for audio hosts and streams, MIDI input and output, OSC sending and receiving, video decoding and playback, cross-platform webcam capture, an Interactive Shader Format pipeline, and laser device control with path optimisation. A single installation can therefore drive a projector, read a webcam, listen for OSC from another machine and send points to a laser projector. That breadth is the real argument for choosing nannou over assembling those pieces yourself.

Bevy underneath: how the sketch API and Draw interface are exposed

The most consequential design decision in the current version is the foundation. nannou is built on the Bevy game engine, and its crates are exposed as a set of Bevy plugins. The README states the consequence directly: nannou's familiar sketch and app API and the Draw interface can be used on their own, or dropped into any Bevy application.

That is a two-way door. If you want the classic experience, you write a nannou app and never think about plugins. If you already have a Bevy project, you can add nannou as a plugin and get the Draw API inside an ECS world you control. The workspace confirms the arrangement: bevy is a workspace dependency pinned to 0.19.0 with default features disabled, and nannou_wgpu sits alongside it as a separate crate.

The repository is a cargo workspace with the version declared once under workspace.package, and every nannou crate inherits it, so releases move in lockstep. The comment in Cargo.toml is explicit that this is the single source of truth for the version of every published nannou crate. For an artist this matters less than for a library author, but it means you should not expect to mix nannou 0.19 and 0.20 crates in one build.

The split also gives you an escape hatch for headless work. nannou_core is described as just-the-core for headless, embedded and libraries, which is the crate to look at if you want geometry or math without a window.

Installing nannou and running a first example

The guide linked from the README covers platform-specific setup, installing Rust, editor setup, running examples, creating a project and updating nannou and Rust. The repository itself does not restate those steps, so the guide is the place to start.

The quickest way to see whether nannou works on your machine is to clone the repository and run one of the bundled examples. The README gives this command, where the example name is the file name without the .rs extension:

cargo run --release --example <example_name>

The README warns that the first run might take a while because nannou has to build first, and that consecutive runs should be much quicker. Build times are the practical cost of a Rust graphics stack, and you should expect the first compile to be measured in minutes rather than seconds.

The examples directory is organised by subject rather than alphabetically, with subdirectories for draw, audio, video, ui, isf, laser, compute, communication, wasm, wgpu, bevy, offline and templates, plus two ported collections. generative_design holds examples from Generative Gestaltung ported from p5.js, and nature_of_code holds examples from Nature of Code ported from Processing. Those two directories are the fastest way for someone arriving from p5.js or Processing to map familiar sketches onto nannou.

For a new project of your own, the guide's create-a-project page is the documented path. The repository layout shows a templates directory under examples, which is the starting point the project provides for new sketches.

Where nannou is the wrong tool

The README says it without hedging: it is still early days and there is a lot of work to be done. Treat that as a statement about the API surface and the surrounding ecosystem, not modesty.

Two concrete consequences follow. First, the project tracks Bevy, and Bevy moves fast. The workspace comment notes that bevy-inspector-egui has no Bevy 0.19 release yet, and that the inspector feature and the inspector_ui example are disabled until one lands. That is a live example of nannou waiting on an upstream dependency, and it is the kind of gap you will hit again. If your project needs a stable API for years, the guide's updating page is required reading before you commit.

Second, the ecosystem argument. Processing and openFrameworks have years of third-party libraries, books, course material and forum answers behind them. nannou has a guide, an API reference, examples and a community tutorial list. That is a real body of documentation, but it is not the same depth, and the README does not pretend otherwise.

There is also a licensing wrinkle worth noticing early. The workspace declares MIT OR Apache-2.0, and the guide has a section on the Apache/MIT dual licensing. The repository metadata used here lists the licence as unknown, so if licence terms are a hard constraint for you, read the workspace manifest and the guide page rather than trusting a badge.

nannou compared with OPENRNDR

OPENRNDR is the closest thing to a direct alternative, and the difference is not cosmetic. OPENRNDR is a Kotlin framework running on the JVM. nannou is Rust, compiled ahead of time, with no virtual machine in the process.

That changes the working rhythm. In OPENRNDR you get the JVM toolchain, its libraries and its debugging story, and hot-reload style iteration is a normal way to work. In nannou you get cargo, a compile step, and a binary you can copy to another machine and run. The README's emphasis on portable code and on installations that run for twelve months points at the second model: you ship an executable, not a runtime plus your source.

The second difference is the engine. nannou sits on Bevy, so its crates are Bevy plugins and the Draw API can be used inside a Bevy application. OPENRNDR has no equivalent integration story with a general-purpose game engine. If your project is mostly a game with a generative visual layer, nannou's arrangement is more useful. If your project is a sketch you want to iterate on interactively with a large library ecosystem behind it, the JVM side is the easier place to be.

Neither approach is a superset of the other. The choice is about which runtime you want to live with.

Maintenance, releases and the upgrade cost

The last push to the default branch was on 2026-07-15, and the most recent release is v0.20.0, tagged nannou-v0.20.0, published on 2026-06-22. The repository is not archived.

Upgrades are coordinated rather than independent. Because every nannou crate inherits a single workspace version, a release moves all of them together, and the version is bumped with a script: the Cargo.toml comment shows cargo run --bin set_version -- "X.Y.Z" as the way the maintainers change it. The workspace also includes release-plz.toml, so release automation is part of the repository.

For an application author the practical cost is the Bevy version underneath. nannou 0.20.0 declares bevy 0.19.0 and bevy_egui 0.40.0 as workspace dependencies. When Bevy makes a breaking change, nannou has to follow, and your sketch may need edits as a result. The guide has a dedicated Updating Nannou and Rust page, which is a sign the project treats this as a routine task rather than an edge case. Budget for it: pin your dependencies, read the changelog before moving, and do not assume a minor nannou bump is free.

On licensing, the workspace declares MIT OR Apache-2.0, and the guide explains the dual licensing under the Why Nannou section. Dual licensing of this kind is permissive and common in the Rust ecosystem, but the repository metadata here does not confirm a licence independently, so verify against the manifest and the individual crate you depend on. That is a factual check, not legal advice.

Editorial conclusion

Adopt nannou if you already write Rust and want one workspace that covers graphics, audio, video, webcam, MIDI, OSC and laser output behind a sketch API you can also drop into a Bevy application. Do not adopt it if you need the mature ecosystem, tutorials and third-party libraries that Processing and openFrameworks have accumulated, or if you cannot accept that the README calls this "still early days". Before committing, run one example from the repository with cargo run --release --example, read the Updating Nannou and Rust page in the guide, and check the CHANGELOG entry for v0.20.0 against the Bevy version you plan to pin.

Frequently asked questions

Official sources

1. Issues
2. nannou-org/nannou on GitHub
3. Project website
4. README
5. Releases