NIH-plug: a Rust framework for VST3 and CLAP plugins

What NIH-plug solves, and who it is aimed at

Writing an audio plugin usually means writing the same scaffolding twice: once for VST3 and once for CLAP, then again for a standalone build. NIH-plug is an API-agnostic framework in Rust that tries to remove that duplication. The README describes the goal as a stateful but simple plugin API that "gets rid of as much unnecessary ceremony wherever possible", while keeping magic to a minimum so different approaches stay easy to try.

The audience is Rust developers who already know what a plugin host is and do not want to hand-write parameter serialization, smoothing and format bindings. It is not a plugin for musicians. The repository contains both the framework crate (nih_plug) and a collection of plugins such as Diopser, Crisp, Crossover and Spectral Compressor, which double as worked examples of the API.

One caveat sits at the top of the README: the framework is in maintenance mode, and readers interested in the framework rather than the plugins are pointed at a community fork on Codeberg. That sentence changes how the project should be evaluated. The plugins remain usable, but the framework's direction is no longer being set in this repository.

How the framework is put together

The repository is a Cargo workspace. The root Cargo.toml lists members including nih_plug_derive, nih_plug_egui, nih_plug_iced, nih_plug_vizia, nih_plug_xtask, cargo_nih_plug, plus the plugins directory and eleven example plugins. The core crate is the workspace root itself, named nih_plug, with edition 2021 and rust-version 1.80.

Format support is opt-in through macros. The README states that adding the corresponding nih_export_<api>!(Foo) macro to your plugin's library is what enables VST3 or CLAP, and that a standalone binary comes from calling nih_export_standalone(Foo) in main(). The default feature set is just vst3. The standalone feature is described in Cargo.toml as disabled by default because it pulls in additional dependencies for audio and MIDI handling; baseview, clap, cpal and jack appear in the feature definition.

Parameters are declarative. You put FloatParam, IntParam, BoolParam and EnumParam<T> fields on a struct, assign stable IDs with #[id = "foobar"], and derive Params. The README says the parameter objects come with built-in smoothers and callbacks, that enums deriving the Enum trait can be matched directly in Rust, and that non-parameter state can be persisted by adding Serde-serializable fields annotated with #[persist = "key"]. Parameters can be nested with #[nested(group = "...")], including arrays of the same parameter. There is also optional support for state migrations when parameter layouts change.

The design trade-off is visible in the feature flags. Splitting GUI toolkits into separate crates keeps the core small, but it means choosing between egui, iced and vizia is a workspace-level decision rather than something the framework hides from you. The assert_process_allocs feature is a good example of the project's priorities: it makes debug builds terminate when an allocation happens inside the processing function, though the Cargo.toml comment warns that panics using string formatting may allocate too, so the feature may need to be turned off while debugging panics in DSP code.

Getting NIH-plug and seeing the API in use

The README does not give a step-by-step install section. It points to the documentation site at nih-plug.robbertvanderhelm.nl, to the cookiecutter template repository nih-plug-template for getting started quickly, and to the Latest builds release page for prebuilt development binaries of the bundled plugins on Linux, Windows and macOS. The macOS note is that Gatekeeper may need to be disabled to use those plugins.

Because the framework is a Rust crate, the practical starting point is a Cargo project that depends on it. The root Cargo.toml declares rust-version 1.80, so a toolchain at or above that version is the floor. The workspace member list is the best map of what a plugin project looks like: plugins/examples/gain, plugins/examples/sine and plugins/examples/midi_inverter cover the small cases, and plugins/examples/gain_gui_egui, plugins/examples/gain_gui_iced and plugins/examples/gain_gui_vizia show the same plugin with each GUI crate.

The repository's own Cargo.toml shows how the pieces are declared. The package metadata for the core crate reads:

[package]
name = "nih_plug"
version = "0.0.0"
edition = "2021"
rust-version = "1.80"
license = "ISC"

And the feature block that decides what a build produces starts like this:

[features]
default = ["vst3"]

Building the workspace compiles the examples and the bundled plugins together, which is the fastest way to confirm the toolchain works before writing anything. Expect the first build to take a while: the standalone path pulls in cpal, jack and baseview, and the GUI crates pull in their own toolkit dependencies. The standalone feature is not in the default set, so a plain build produces the VST3 target the default feature enables rather than a standalone binary.

Where NIH-plug stops being the right choice

The maintenance-mode notice is the first limitation, and it is not a small one. Anyone starting a new plugin framework project today is being told by the README to look at the community fork instead. That does not make the code unusable, but it means bug reports and design questions about the framework may not be answered here.

The second limitation is scope. NIH-plug targets VST3 and CLAP. Audio Units are not in the feature list or the export macros, so a macOS AU build is not something the framework offers. If AU is a requirement for your distribution, this is the wrong tool.

The third is the audio-thread discipline. Rust makes it easy to write code that allocates, locks or formats strings without noticing, and a plugin's process function cannot do any of that. The assert_process_allocs feature exists precisely because the compiler will not catch this for you, and the Cargo.toml comment about panics allocating shows how sharp the edge is. A developer without prior real-time audio experience will spend time on this before shipping anything.

Finally, the bundled plugins are not a product line. The README describes Puberty Simulator as a joke and Loudness War Winner as something with "dissatisfaction guaranteed". They are demonstrations of the framework and personal tools, not a supported plugin suite with release cadence and support channels.

How NIH-plug differs from writing against a C++ framework

The obvious alternative is JUCE, the long-standing C++ framework for audio plugins. The difference in approach is structural rather than cosmetic. JUCE ships a large class library covering audio, GUI, formats and more, and you build your plugin inside that library. NIH-plug is a Rust crate that leans on the Rust ecosystem instead: Serde for persisted state, Cargo for the build, and separate crates (nih_plug_egui, nih_plug_iced, nih_plug_vizia) for GUI toolkits rather than one bundled widget set.

That shows up in the parameter system. In NIH-plug you declare fields, attach stable IDs with attributes and derive Params; smoothing and callbacks are described as built in. The README's framing is that the API should be stateful and simple with minimal magic, which is why parameter groups, nested parameters and persisted non-parameter state are all expressed as attributes on your own struct rather than as framework-owned objects.

The trade-off is ecosystem maturity. JUCE has years of third-party tutorials, books and commercial support behind it. NIH-plug asks you to be comfortable in Rust, to accept the maintenance-mode notice, and to work with a smaller set of GUI options. If your team already writes C++ and ships AU alongside VST3, moving to NIH-plug means giving up both the language and the format coverage.

Licence, upgrades and the cost of staying current

The repository is licensed under ISC, a permissive licence, and the root Cargo.toml carries license = "ISC". That is permissive enough for closed-source plugins, but the bundled plugins may carry their own terms: Soft Vacuum is described as a port of Airwindows' Hard Vacuum with credit to Chris from Airwindows, and porting someone else's plugin raises questions the ISC file in this repository does not answer. Check each plugin directory before redistributing binaries. Nothing here is legal advice.

The upgrade story is thin. The package version in Cargo.toml is 0.0.0, which signals that no semantic versioning contract is being offered. The releases page hosts a tag called latest-builds, updated on 2026-09-03, which is a rolling build of development binaries rather than a versioned release. The README mentions optional support for state migrations for handling breaking changes in plugin parameters, which is the framework's own acknowledgement that saved sessions can break when parameters change. If you ship plugins built on this, plan on writing those migrations yourself, and plan on reading CHANGELOG.md before pulling new commits, because there is no version number to pin against.

Editorial conclusion

Adopt NIH-plug if you want a Rust plugin skeleton with declarative parameters and VST3/CLAP export macros, and you accept that the README says the framework is in maintenance mode. Do not adopt it if you need a framework that is being developed further; the README points to a community fork instead. Before committing, verify three things in the repository: that the rust-version in Cargo.toml matches your toolchain, whether you need the standalone feature (it is not in the default feature set), and which GUI crate fits your target, since nih_plug_egui, nih_plug_iced and nih_plug_vizia are separate workspace members.

Frequently asked questions

Official sources

1. Issues
2. License: ISC
3. README
4. Releases
5. robbert-vdh/nih-plug on GitHub