lly plugin

Manage the plugins that extend lly.

The lly binary is small on purpose. Everything beyond the core compile and run loop ships as a plugin: language frontends like frontend-c and frontend-cpp, framework compilers like nextjs, and operations utilities like void. Plugins are signed binaries installed under ~/.lly/plugins/<name>/. The lly plugin subcommand is how you list, install, inspect, and remove them.

Plugins are resolved through rc.lilylabs.io, the LILY registry. Each plugin has a manifest, a per-platform binary (currently x86_64-linux and aarch64-macos), and a detached signature. lly verifies the signature before the plugin ever runs.

Subcommands

lly plugin list — show every installed plugin with its version and kind. Example: lly plugin list.
lly plugin info <name> — print the full manifest for one plugin: version, kind, supported extensions, install path, sha256. Example: lly plugin info nextjs.
lly plugin which <ext> — answer which frontend handles a given file extension. Example: lly plugin which .cpp.
lly plugin verify <name> — re-check the on-disk binary against the manifest signature and hash. Example: lly plugin verify void.
lly plugin install <name> — resolve the latest version from rc, download, verify, and install. Example: lly plugin install nextjs.
lly plugin remove <name> — delete the plugin from ~/.lly/plugins/. Example: lly plugin remove nextjs.
lly plugin update <name> — re-resolve and upgrade in place. See the note below.
lly plugin enable <name> — mark a previously disabled plugin as active again. Example: lly plugin enable frontend-cpp.
lly plugin disable <name> — keep the binary on disk but stop dispatching to it. Useful for A/B testing two frontends. Example: lly plugin disable frontend-cpp.
lly plugin path — print the absolute plugins directory (typically ~/.lly/plugins). Example: lly plugin path.

Install a plugin

Installing a plugin is a single command. lly contacts the registry, fetches the manifest, downloads the binary for your host triple, checks the signature, and drops it into the plugins directory.

install

$ lly plugin install nextjs → resolving nextjs from rc.lilylabs.io manifest: nextjs@0.4.1 (x86_64-linux, 11.4 MB) sha256: 9c64657f1a3d…b8e0 → downloading binary ✓ verified signature (ed25519, key rc-2026-q2) ✓ installed to ~/.lly/plugins/nextjs/ · nextjs (util) · handles: lly nextjs <build|dev|render|export|void> $ lly plugin list NAME VERSION KIND INSTALLED frontend-c 0.8.2 frontend 4 days ago nextjs 0.4.1 util just now void 0.3.7 util 2 days ago

Inspect what is installed

Use lly plugin info to see exactly what a given plugin claims to be and where it lives. The which verb answers the inverse question: given a source extension, which frontend will lly compile dispatch to.

info

$ lly plugin info nextjs name: nextjs version: 0.4.1 kind: util path: ~/.lly/plugins/nextjs/nextjs sha256: 9c64657f1a3d…b8e0 signature: ed25519 (rc-2026-q2) subverbs: build, dev, render, export, void $ lly plugin which .cpp frontend-cpp (handles .cpp .cc .cxx .hpp)

Disable without uninstalling

Plugins can be turned off without removing the binary. A disabled frontend is skipped during extension dispatch; a disabled util is hidden from the top-level help. Re-enable with lly plugin enable. This is the right tool when you want to compare two frontends side by side or when an experimental version of a plugin is misbehaving and you need to fall back fast.

Where plugins live

Every plugin is a single static binary under ~/.lly/plugins/<name>/, alongside its manifest and signature. lly plugin path prints the directory, which is handy when you are scripting installs or auditing what a machine has. Plugin binaries never write outside their own directory, and they cannot escalate beyond the user that invoked lly.

For background on how plugins are built and published, see the rc registry. For the plugins you most often reach for, see nextjs and void.