How to obfuscate and protect a Luau script. Near native by default, stronger on request.

Protecting a Luau script means producing a separate, hardened artifact from your private source and shipping that instead. On vodka this is one build with layers: by default it rewrites your source so the output runs within noise of the original, and an opt-in mode adds a bytecode virtual machine when a script needs it. You keep the original, players get the protected version.

Set your expectations honestly at the start. Obfuscation raises the cost of reading and copying your code. It does not make a delivered value permanently secret, because an authorized client still receives the code it runs. That boundary is covered in Roblox script obfuscation explained; this guide is the how-to.

Every build runs a set of source rewrites with no toggle required. They change how the program is written without changing what it does:

• Encoded constants. Strings and numbers are replaced with expressions whose decode key is derived at runtime, so literal secrets are not sitting in plain text.
• Flattened control flow. The shape of supported code is rearranged so it is harder to read top to bottom.
• Renamed locals. Local and upvalue names are rewritten with scope awareness, so meaningful names do not survive.
• Minified, watermarked output. The result is compacted and carries a per-build identifier.

Because it targets Luau, the build preserves what Luau programs depend on: type annotations are kept, string interpolation is handled at the source level, and globals, table fields, method names and type names are never renamed. There is a Lua 5.1 compatibility mode when you need it. See the Luau obfuscator page for the specifics.

When secrecy matters more than speed, turn on Maximum protection for that script. Supported functions are compiled to bytecode and interpreted by a generated per-function virtual machine, with self-integrity anti-tamper, on top of the default transformations. Functions outside the supported set keep native execution, so behavior is preserved.

It is off by default for a reason: interpreting bytecode is slower than running native Luau, and that cost shows up most on hot or looping code. The honest rule is to enable it where the logic is worth hiding and leave it off where the script spends its time. The benchmarks publish the overhead with the commands to reproduce it.

Do not guess at the runtime cost, and do not take a vendor's single number as yours. Protection overhead depends on what your script does. A UI script that reacts to clicks will not feel the VM; a render-step loop or a tight physics routine might.

Measure before and after on the code you actually run. Wrap your hot path in an os.clock() loop, or watch it in the Roblox MicroProfiler, and compare the default build against Maximum protection. If a section is too expensive with the VM on, you can keep the VM for the sensitive functions and leave the hot loop on the default transformations.

Every protected artifact is parsed and compiler-checked before it can publish, and a failed or cancelled build never replaces your working release. But a valid build only proves the artifact compiles, not that your script behaves in its real environment.

Test the published release where it will run, with its dependencies, callbacks, error paths and any key expiry, before you share it. Read what each protection layer does for the full reference, and if you plan to gate access, pair this with how to add a key system.