Per-function virtualization
Supported functions are represented as bytecode interpreted by a generated VM. Functions outside the supported set retain native execution alongside the other transformations.
Documentation / Protection
Your protection. Under the surface.
A per-function bytecode VM, source transformations and a checked release pipeline. Understand what vodka applies to your code and where client-side protection has limits.
One integrated pipeline
Original source in. A protected build out.
vodka applies its protection pipeline automatically when you build. The original is retained separately from the output your authorized players receive.
The pipeline compiles supported functions into a per-function Luau bytecode VM, encodes strings and numbers, transforms control flow, rewrites local names, minifies output and adds a recoverable per-build watermark.
What each layer does
Different layers. Different jobs.
Constants and control flow
Strings and numbers are replaced with encoded expressions, while control-flow transformations change how supported portions of the program are represented.
Names, output and watermark
Local and upvalue names are rewritten with scope awareness. Output is minified and watermarked per build. The watermark is a build identifier, not proof of tamper resistance.
Validation before publication
The generated artifact is parsed and compiler-checked before it can become the published release. Failed, stale or cancelled builds do not replace the current working artifact.
Access and storage
Keep the trust on the server.
Before delivery.
Server-side checks decide whether a script and its published artifact are available and whether a presented key meets access conditions. Expiry, revocation, account suspension and rate limits remain relevant even when player premium is active.
Originals, drafts and protected artifacts are stored with application-level encryption. Owners can access their own source; authorized administrator inspection is audited.
After delivery.
An authorized client can inspect delivered code and runtime behavior. Protecting source raises the effort of casual inspection; it cannot make every client-side value permanently secret or undo code already delivered.
Roblox account and place IDs reported by the runtime are not independent proof of identity. Review the privacy statement for storage, activity and retention details.
Evaluate with evidence
Test the script you actually ship.
Check behavior in your intended environment, including startup, dependencies, callbacks, errors and key expiry. Test a small update before changing your main published release.
No independent comparative security or performance benchmark is presented here. VM use, output size and visually complicated code alone do not establish that one service is more secure than another.
Protection questions
Clear expectations, before you build.
01Does every function run inside the VM?
No. Supported functions are compiled into a per-function Luau bytecode VM. Functions that the VM does not support keep native execution alongside the other source transformations.
02Does a successful build prove my script will work everywhere?
No. Parsing and compiler validation check the generated artifact. You still need to test the script in your intended environment, including its dependencies and access flow.
03Can obfuscation keep a client-side secret permanently hidden?
No. An authorized client receives protected code and can inspect its runtime behavior. Keep credentials and decisions that require trust on a server. Obfuscation is not a permanent secrecy guarantee.
Keep building
Build your first protected release.
Start with original Lua or Luau source and test the result in your environment.
vodka / Product notesUpdated