How to add a key system to your Roblox script. Free, and enforced on the server.

A key system decides who is allowed to run your script. The player completes a step you set, redeems a key, and your loader only hands over the real code once that key verifies. Done well it cuts casual copying and gives you a way to revoke access later. Done badly it is a speed bump that a determined person steps over in a minute.

The whole difference is where the check runs. On vodka the key, its expiry, revocation and HWID lock are all decided on the server, in the verify handshake, never in the code you hand out. That matters, because anything a client can read it can also edit. A key check written into the distributed loader is not really a check. This guide adds a key system the honest way, and it is free for you and your players. For the protection underneath it, read how to obfuscate and protect a Luau script.

A key is useful for one job: gating delivery of your script and giving you a lever to pull when access needs to stop. It cannot keep a secret that you ship inside the script itself, because the authorized player receives the code they run. So before you add tasks, separate the two concerns.

• What the key gates: access to your loadstring, so only people who redeemed can run the current release.
• What stays on the server: any decision or value you cannot afford to leak. vodka already keeps the key check, expiry, revocation and HWID lock server-side so the loader cannot grant itself access.
• What a key is not: proof the script ran, or proof someone joined your group. A delivery count is not an execution, and a link visit is not verified membership. Keep those honest in your own head and your community will trust the numbers.

In the script workspace you turn the key system on and shape it to your audience. Every setting here is enforced in the server-side key system, not trusted to the client:

• Free-key tasks and their order. Decide what a player does to claim a key, and the order they do it in. If you monetize, your own ad-link provider becomes one of these steps and pays you directly. See how creator earnings work.
• Key lifetime. Short lifetimes mean players re-claim more often, which can feed monetization but adds friction. Pick a duration that fits your script, not the biggest number.
• HWID locking. Bind a key to the first device that runs it so one key is not shared across a server. It is opt-in and reversible, with bounded player self-service resets. Read HWID locking explained.
• Revocation and blacklist. Keep the ability to kill a specific key or block an abusive user. This is what makes a leak recoverable rather than permanent.

Publishing gives you one stable loadstring. Future published builds reuse the same delivery address, so you never have to hand your community a new loader just because you shipped an update. That one line is what your players paste.

Redemption is easiest where your players already are. vodka ships a Discord bot: run /setup once and it builds a get-key channel and a redeem button, players run /redeem to validate a key and get their role, and the loadstring comes back in an ephemeral reply only they can see. You issue, revoke and read stats from the same chat. The full walk-through is in how to set up a Discord key bot.

A key system you have only tested with a valid key is a key system you have not tested. Run the unhappy paths before you point anyone at it:

• Redeem a valid key and confirm the script runs end to end, including its callbacks and error paths.
• Let a key expire, or issue a short one, and confirm the loader refuses it cleanly.
• Revoke a key mid-session and confirm access actually stops on the next verify.
• Try a second device against an HWID-locked key and confirm the lock holds, then test a self-service reset.
• Request the loadstring with no key and confirm nothing useful comes back.