Lune is a standalone Luau runtime written in Rust

A runtime in the shape of Node

Lune is a standalone Luau runtime, and the README positions it against the runtimes people already know, with Node, Deno, Bun and, for vanilla Lua, Luvit as the comparisons. The model is a single binary you run scripts with, not a library you embed, and the two implementation decisions behind it are stated in one line. Lune provides fully asynchronous APIs wherever possible, and it is built in Rust for speed, safety and correctness. That pairing is the interesting part. A Luau runtime written in a memory safe language can expose an asynchronous filesystem and networking API without the process-wide locks that a scripting language runtime would otherwise need, and the project backs that up with a crate list where every standard library area is its own crate, including one for the Luau scheduler binding.

Minimal interface, complete standard library

The feature list is short and each entry is a design decision. The interface is strictly minimal but powerful, easy to read and remember, just like Luau itself. The APIs are fully featured for the filesystem, networking and stdio, and all of it is included in the small executable, which is about five megabytes zipped. Documentation is on the web or directly in the editor, with no network connection necessary, which matters for a tool that Roblox developers often run inside editors that already have a Luau language server. The runtime environment is familiar to Roblox developers, with an included one to one task scheduler port. And there is an optional built-in library for manipulating Roblox place and model files, and their instances. The last item is the one that turns Lune from a generic Luau runner into a Roblox toolchain component, because editing a place file is a structured task that a general purpose language would need a third party library for.

The non-goals explain the design

Many projects would not list what they are not trying to do, and Lune does, with two entries that explain most of the choices above. The first is that making programs short and terse is not a goal, because proper autocomplete and intellisense make using Lune just as quick, and readability is important. That is a defensible position for a runtime whose whole appeal is that it drops into an editor that already has a good Luau language server, and it is the opposite of the golfing culture of the Lua world it comes from. The second is that running full Roblox games outside of Roblox is not a goal, since there is some compatibility but Lune is meant for different purposes. So a Lune program is a script that works with Roblox data, not an emulator of the Roblox engine, and that boundary keeps the runtime small.

The crate list is the API surface

The workspace member list in the Cargo manifest is the most precise description of what the runtime contains. There is crates/lune, the runtime itself, and crates/lune-roblox for the Roblox pieces. The standard library is split into one crate per area, with lune-std as the umbrella and separate crates for datetime, fs, luau, net, process, regex, roblox, serde, stdio and task, plus lune-utils for shared helpers and mlua-luau-scheduler for the scheduler binding that makes the Roblox style of task library work. Two observations follow from that structure. The task crate is the reason the runtime can claim a one to one task scheduler port, since the binding sits at the boundary with the Luau VM. And the split into single-purpose crates means the surface area of the runtime is enforced by the build, since a new API is a new crate rather than another function in a growing module.

The release profile is tuned for a small binary

The release profile shows what the project is optimising for, and the comments explain the reasoning in detail. The settings are to optimise for size, to automatically strip symbols from the binary and to enable link-time optimization:

[profile.release]
opt-level = "z"
strip = true
lto = true

The comment adds a nuance that is easy to miss. They could abort instead of panicking to cut the size down even more, but because the filesystem and some other APIs are used, they need the panic unwinding to properly handle the usage of those APIs. That is the trade between a smaller binary and correct error handling on the paths that touch the operating system, and the project resolved it in favour of correctness. The workspace is set up with a resolver version of 2 and crates/lune as the default member, so a plain cargo build in the workspace root builds the runtime rather than the whole tree of standard library crates.

A strict lint policy in the workspace

The workspace lint configuration is unusually explicit, and it reads as a statement about what the project values. All lints are errors by default, and the cargo and pedantic clippy lints are downgraded to warnings, and then a set of specific pedantic rules are allowed back in. The allowed list is a good description of the code's style, since it permits casts between number types, module naming conventions, imports and multiple dependency versions, and similar names and unnecessary wraps. The workspace declaration is short:

[workspace]
resolver = "2"
default-members = ["crates/lune"]

For a project whose public surface is a scripting API, that combination is sensible. The internal code is held to a strict standard, while the ergonomics of a library that people call with one argument are allowed to be a little looser.

Tooling and the current state

The repository shows the small pieces of tooling a Luau project needs, with a rokit.toml for the toolchain, a .luaurc for the Luau language server configuration, a .lune/ directory for Lune specific settings, stylua.toml for formatting Lua, a scripts/ directory, a tests/ directory and a Cargo.lock, plus the .cargo/ directory for Cargo configuration. The project is on crates.io as lune, and the documentation site is lune-org.github.io/docs, with the installation page as the entry point. The release history is v0.11.0 published on 2026-10-11, v0.10.5 on 2026-07-02 and v0.10.4 on 2025-10-14, so the version is still in the zero series and the cadence has picked up. The last push was on 2026-10-11, the repository is not archived, and the licence is MPL-2.0, the file level copyleft Mozilla publishes, which fits a runtime that is distributed as a binary and used by a large Roblox community.

Editorial conclusion

Lune fits a Roblox developer who needs to script the parts of their work that are not the game itself, editing place files, running a build step, or moving data between a Roblox project and the rest of their toolchain, because the runtime speaks Luau rather than a different language. It does not fit someone who wants to run a full Roblox game outside Roblox, since that is an explicit non-goal. It does not fit a team that wants a large standard library, since the project describes its interface as strictly minimal by design. Before you adopt it, read the non-goals, because they explain most of the design decisions, and note the release state, where 0.11.0 was published on 2026-10-11 and the last push was the same day.

Frequently asked questions

Official sources

1. License: MPL-2.0
2. lune-org/lune on GitHub
3. Project website
4. README
5. Releases