Rune in one page.

A Rune is a directory under plugins/Rune/scripts/ with a manifest and an entry script. Decorators in the entry script register event listeners and commands; modules under it hold the rest of the logic. On server start, Rune discovers every directory, hands its entry to the matching language runtime, and replays decorator registrations against Paper.

plugins/Rune/scripts/
└── ward/
    ├── rune.toml       # publish-side manifest (CLI cares about this)
    ├── rune.jsonc      # runtime manifest (the host cares about this)
    ├── index.ts        # entry — registers listeners + commands
    ├── commands/
    ├── lib/
    ├── models/
    └── web/

The two manifests serve different audiences: rune.toml is what rune publish reads when packing for the Runebook registry; rune.jsonc is what the running host reads to know which third-party plugins your Rune asks for and what aliases to bind. They overlap on identity (name, version, language) but stay separated so a Rune can run un-published.

The runtime story is more aggressive than "run a script." Rune ships a Rust loader compiled to a shared library that the Paper plugin loads via Panama FFM. The loader hosts language backends; today only Node.js (V8 via libnode) is wired, with Wasmtime stubbed in as a second runtime. Languages get added by implementing a single trait — Python, Lua, and Rust-to-Wasm are on the roadmap.

If you've never run a Rune:

• Quickstart — From zero to a running Rune in under five minutes.

If you're writing one and want a feature-by-feature reference, jump to listeners, commands, or HTTP servers. If you want to ship one, publishing walks you through the registry flow.

Every example in these docs is drawn from ward, a full-stack permissions plugin written entirely in Rune. It has decorator-based commands, an inventory-driven admin UI, a MongoDB-backed schema, a PlaceholderAPI expansion, a Vault economy integration, and a web dashboard served over HTTP from the same process. If a Rune feature exists, ward exercises it.