# Noctalia v5 replaces QML-first plugins with isolated Luau runtimes Noctalia v5.0.1 is officially stable, and the Wayland shell’s extension model has changed substantially: plugins now use manifests plus Luau scripts running in isolated VMs off the UI thread, with bounded execution and a native runtime API for processes, HTTP, files and persistent state. The interesting change is not another desktop-shell release. Noctalia has moved plugin logic away from the older QML-centric model into isolated scripting runtimes, creating a clearer extension boundary while still treating plugins as trusted code. - Status: Active - Published: 2026-09-07T15:05:05+12:00 - Updated: 2026-09-07T15:05:05+12:00 - Categories: Web Development, Developer Tools - Tags: desktop shell, Luau, Noctalia, plugins, Wayland - Canonical HTML: https://beyondthe.news/dossiers/noctalia-v5-stable-native-luau-plugin-runtime ## 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. ## Key details - Noctalia v5.0.1 is marked officially stable in the project changelog dated September 3, 2026. - The v5 plugin format uses `plugin.toml` manifests and Luau scripts. - Plugin entries run in separate isolated Luau VMs. - Runtime work is moved off the shell UI thread and subject to execution-time budgets. - The runtime exposes process, HTTP, filesystem and persistent-state capabilities. - Noctalia still treats plugins as trusted code rather than a safe sandbox for arbitrary third-party code. ## Builder takeaways - Treat v5 as an extension-architecture migration, not merely an in-place theme update. - Port v4 QML-centric plugins against the documented v5 manifest/runtime APIs instead of assuming source compatibility. - Keep expensive or blocking work inside the asynchronous runtime APIs rather than UI callbacks. - Review plugin source and provenance before installation because runtime isolation does not remove process, network or filesystem authority. - Pin and test shell/plugin versions on managed desktops until the new v5 ecosystem settles. ## What to watch - How quickly commonly used v4 plugins migrate to the v5 runtime. - Whether Noctalia adds finer-grained plugin permissions or capability declarations. - Stability data as more users move from beta to the stable v5 branch. - Whether other programmable Wayland shells adopt similar off-UI-thread scripting boundaries. ## Uncertainties - The stable v5 plugin ecosystem is still young, so long-term API compatibility and failure patterns are not yet established. - VM isolation improves runtime separation but is not documented as a hostile-code security sandbox. - Third-party plugin migration pace will determine how disruptive the architectural change is for existing users. ## Sources - [Noctalia changelog](https://noctalia.dev/changelogs) — Noctalia · primary changelog · 2026-09-03T00:00:00+12:00. Canonical confirmation that v5.0.1 is officially stable. - [Noctalia documentation](https://docs.noctalia.dev/noctalia/) — Noctalia · primary documentation. Current v5 architecture and setup documentation. - [Plugin development](https://docs.noctalia.dev/noctalia/plugins/development/) — Noctalia · primary documentation. Current manifest, Luau VM and plugin-development model. - [Plugin runtime API](https://docs.noctalia.dev/noctalia/plugins/development/runtime-api/) — Noctalia · primary documentation. Runtime process, HTTP, filesystem, state and execution-boundary documentation.