Getting Started

FlareKey sits between your customers and your protected Lua. Instead of shipping raw source, you register a script once, hand out license keys, and choose either a generated v2 loader or Script Library to decide who receives the real code and when. Everything is organized under a service. Generated loaders use a short-lived ticket; custom loaders use a short-lived Library token and execution grant. This page covers the core objects and the exact order each path calls them.

What FlareKey Is

FlareKey is the licensing and delivery layer for protected scripts. You create services, attach scripts, generate customer license keys, verify those keys at runtime, and deliver source through short-lived tickets.

Service vs Script vs License Key

A service is the product container. A script is a protected asset inside that service. A customer license key normally unlocks one script, while optional service-wide keys can unlock every script in that service.

Runtime Session vs Customer Key

A customer license key identifies the buyer. A v2 loader creates a short-lived, session-bound runtime authorization and never carries the service-wide publisher/runtime key. Keep publisher credentials in dashboard/admin workflows only.

1. Owner creates a service and script.
2. Owner generates a script-specific customer license key.
3. Loader calls POST /v1/licenses/verify with the service ID and customer license key using protocol v2/session binding.
4. Verify returns a short-lived session token and signed challenge transcript.
5. Loader requests a script ticket.
6. Loader downloads signed metadata plus the exact ticket-bound artifact.
7. Loader downloads the protected script with the single-use ticket.
8. The source runtime guard validates the signed delivery metadata before real code runs.

• Start by creating one service, then add at least one script and generate a customer license key for it. Nothing verifies until those three exist.
• Generate a v2 loader from the dashboard after enabling session-bound delivery. The shipped loader needs the service ID and customer license key, not a service-wide runtime key.
• The customer license key starts the runtime session. The server then issues clearance, an exact-build ticket, and signed delivery metadata; none of those values is a reusable service-wide capability.
• Verification never returns source directly. It returns a short-lived session token; the loader then trades that token for a single-use ticket, and only the ticket downloads the code.
• Everything a public loader can see is public. Never place management, publisher, billing, Discord bot, or database secrets anywhere a customer can reach.

Choose a delivery path

• Generated v2 loader: generate the loader from the dashboard. It performs the session-bound protocol, requests a single-use ticket, validates the signed delivery metadata, and downloads the exact protected build.
• Script Library: enable Library mode on the script and maintain your own loader. It verifies with POST https://library.flarekey.xyz/v1/licenses/verify, downloads with a one-use libdl_ token, validates the artifact HMAC, and activates the matching one-use exec_ grant. See Script Library.

The two paths share license, device, Discord, blacklist, and exact-build policy checks, but their tokens and request sequences are not interchangeable.