What changed
Noctalia’s canonical changelog now marks v5.0.1 as officially stable after the v5 beta series. The v5 generation introduces a native runtime and a new plugin model built around `plugin.toml` manifests and Luau entry scripts. Each plugin entry runs in its own isolated Luau VM rather than executing application logic directly in the shell’s QML UI layer. Noctalia’s runtime exposes asynchronous process execution, HTTP, filesystem access and state APIs, and applies per-call execution budgets so plugin work does not monopolize the UI thread. The project’s older v4 plugin documentation describes a QML-file model, making this a real architecture migration rather than a cosmetic version bump.
Why it matters
Desktop shells are increasingly programmable platforms, but extension code can easily turn into a reliability and security boundary. Separating plugin logic from the UI thread and giving it a constrained runtime makes long-running or faulty extensions easier to isolate conceptually, while a defined API reduces the need for plugins to reach directly into shell internals. The caveat is important: Noctalia still treats installed plugins as trusted code, and runtime access to processes, networking and files means isolation is not a general-purpose security sandbox.
Stable v5 resolves the release-state uncertainty
Earlier v5 surfaces were still beta, so BTN deferred the story rather than treating specialist reports as canonical. Noctalia’s own changelog now explicitly says v5.0.1 is officially stable, removing that ambiguity.
Plugin logic moves out of the QML-first model
The previous plugin model centered on QML files for widgets and shell integration. In v5, manifests describe the plugin and Luau scripts provide runtime logic, giving extensions a more explicit separation between UI integration and executable behavior.
Each entry gets an isolated Luau VM
Noctalia documents separate Luau virtual machines for plugin entries, executed away from the UI thread with bounded per-call time. That reduces the chance that one extension’s synchronous work freezes the shell, although it does not make untrusted plugins safe.
The runtime is deliberately capable
The plugin runtime includes asynchronous process execution, HTTP access, filesystem operations and retained state. That makes plugins useful for real desktop automation, but it also means users should apply the same trust discipline they would to other locally installed code.