canary This is the canary — an unreleased build of Roswaal, and not the one to start from. The stable build
Roswaal
0.97.4Visual scripting for Luau, reimagined. Completely free, forever.
Graphs live on disk as .nodescript files and compile to plain
.luau that Rojo syncs like any other source file. No plugin, no
runtime, nothing of Roswaal's left in your game — and it is 0BSD, so the
code and the graphs are yours to keep, sell, or walk away with.
Runs locally on a computer, or online on a computer, tablet or phone: the canary, with nothing to install and your project kept in your browser.
Compiles for Roblox stable and Lune experimental
The graph you see
The Luau it writes
local Players = game:GetService("Players")
Players.PlayerAdded:Connect(function(player: Instance)
print(player)
end)Both halves are built from the same graph, by the same compiler the editor runs — so the picture cannot show a wiring the code does not have.
You own all of it
A .nodescript is a file in your repository — commit it,
branch it, review the diff. Roswaal is 0BSD: no attribution, no
licence to outgrow, nothing to ask permission for.
The output is ordinary Luau
Typed, commented and formatted with your own stylua. Roswaal refuses to overwrite a generated file you have edited by hand.
Try it on your own project
On a computer, the browser version opens a real folder and writes into it, so you can find out whether this fits your game before installing anything.
Inside the editor
Search literally, or visually
Right-click the canvas to search nodes by name. Ctrl + Right-click asks the same question the other way — a picker that draws each node as you walk the list. One for when you know the name, one for when you know the shape.
Custom Code, and Luau Expression
Two escape hatches, on purpose. Write Luau where writing Luau is simpler, and wrap code you already have instead of rebuilding it as nodes. The text is emitted verbatim.
Custom nodes, created your way
Design one in Node Design — wire the logic from nodes and watch the Luau appear beside it, or write the template by hand, switching whenever you like. Or write the pack yourself, JSON or Luau, in whichever editor you already use.
Suggest an edit from any page
Found a mistake, or a graph that is wrong? Every documentation page has a ✎ beside its title that opens an issue with the page already named — and in the editor's own docs window you can change the page in place and propose exactly what it should say.
Documented, node by node
A reference page for every node, with the graph and the Luau it compiles to on each one, and Ctrl + K to it from anywhere in the editor. Plus a guide for anyone Coming from Blueprints.
Preview anything, any time
P shows what the graph in front of you compiles to — a whole script, one function, or just the nodes you have selected. It reads the generated file and picks those lines out of it, so it is the real output rather than a guess at it.
What is planned
Plans rather than promises, in no particular order, and with no dates. Any of it may change, arrive in a different shape, or be dropped — and none of it is in the version you can try today.
Wally packages
Read wally.toml, resolve Packages/, and
offer what a package exports as nodes you can place.
Import Luau you already have
Statements become the flow, expressions become nodes, and anything that will not lower cleanly arrives as a Custom Code node holding the original text — so an import is useful before it is perfect.
A real Luau parser
What the importer needs, and two things that already want it: an exact
check instead of counting brackets, and true block scoping so a local
declared inside an if stops being offered after it.
Read a Rojo project as a node map
The inverse of the translation Roswaal already does, so an existing
default.project.json can come in rather than be rebuilt.
Runtime errors that point at a node
The compiler already writes down which node produced which line.
Nothing reads it in the other direction yet — an error at
Main.server.luau:42 could light up the node that wrote
line 42.
Overriding a built-in node
Keep a node's default behaviour and let a project replace its internals. Honestly, this one is a versioning problem wearing a feature's clothes: what should happen when the built-in changes underneath an override?