DEV Community: Kasun Hapangama

Your Minecraft plugin leaked. Here's how to find who leaked it and stop the copies

Kasun Hapangama — Fri, 06 Nov 2026 20:53:52 +0000

You search your plugin's name and there it is: your premium jar, free to download on a leak forum. It happens to almost every plugin that sells well, and it tends to happen the week of a big release or sale.

Here's what to do in the first hour, in order, and how to set things up so the next leak takes five minutes instead of a weekend.

1. Don't run the leaked file

Leak sites are a common way to spread malware: "cracked" jars often carry a backdoor that was added after the leak. Download the file only to inspect it, in a throwaway folder or a VM. Never put it on a server, not even a test one.

2. Find out whose copy it is

This only works if every buyer got a unique copy. If they did, you have three ways to find the buyer.

Look for the key in the jar. If you sell on BuiltByBit with an External license key placeholder, or on Voxel Shop or SpigotMC with their buyer placeholders, the store wrote something unique into each download. A jar is just a zip file:

mkdir leak && cd leak && unzip -q ../leaked.jar
grep -r "%%__" .                                   # a placeholder nobody replaced?
grep -rlE "[A-Z0-9]{4}-[A-Z0-9]{4}-[A-Z0-9]{4}" .  # files that contain a key
strings path/to/Match.class | grep -E "[A-Z0-9]{4}-"

If the placeholder was replaced, you'll find the buyer's key or user ID in a class file or in config.yml. If the class is hard to read, open it in a decompiler (Recaf, JD-GUI) and look at its constants.

Look for a watermark. If your downloads carry a mark (a line in the manifest, an archive comment, an ID compiled into a class), read it back the same way.

Ask your license server. Search for the key you found. It points to the license, and the license to the buyer. Its activations tell you more: a key on twelve servers in four countries is a shared key, not a stolen account.

A careful leaker may have swapped the key for another, or cut the check out entirely. Then the watermark and your license server's logs (which key started showing up on new servers when the leak appeared) are your best leads.

If every buyer got the same jar, you can't trace this leak. Skip to step 5, and make sure the next version is traceable.

3. Stop the leaked copies

Revoke the buyer's key. If your plugin checks its license on startup and re-checks every few hours, every copy of that jar stops at its next check, on every server that downloaded it. Your other buyers notice nothing.

Two things make this work:

Re-check while running. A startup-only check stops new installs, but servers that were already running keep going until they restart. A re-check every few hours reaches them.
Don't punish a network outage. Only stop on a clear "revoked" or "suspended" answer, never on a timeout. That keeps you on the right side of BuiltByBit's DRM rules, and keeps paying customers safe when your license server has a bad day.

If your plugin has no license check yet, this is the step you can't do today. How to add license keys to a Minecraft plugin in 10 minutes fixes that for the next version.

4. Deal with the buyer

Look at their history before you assume the worst. Sometimes their account was compromised, or a staff member they trusted shared it. Then:

Refund or chargeback? If they charged back, revoke and move on. Stores don't always tell your license server about refunds (BuiltByBit's placeholder doesn't), so check.
Report them to the marketplace with your evidence: the key, the leak URL, the date.
Give a second chance if it was an accident: issue a new key and ask them to keep it private.

5. Get the post taken down

Most leak sites are hosted somewhere that responds to copyright notices. Send a DMCA takedown to the site, or to its host if the site ignores you, with:

a link to your original listing,
the exact leak URL,
a statement that you own the copyright and didn't authorise the copy.

BuiltByBit has its own DMCA form for copies uploaded there. Expect reposts, and don't spend your week chasing every mirror: revoking the key in step 3 already made those copies useless for anyone who restarts.

6. Make the next leak traceable

If this leak was hard to trace, fix it for the next version:

One key per buyer, written into each download by your store's placeholder.
A server limit per key, so a shared key gets refused on the third server.
A startup check with a re-check every few hours, that keeps running when your license server can't be reached.
Alerts for shared keys: one key on many servers, or in two countries an hour apart.
Obfuscation and a sealed core, so the check is hard to cut out of the leaked jar. See How to obfuscate a Minecraft plugin.

How I handle this with SunLicense

I build SunLicense, so here's the same process in it:

Each BuiltByBit download gets the buyer's key through the placeholder. The license is named after their BuiltByBit user ID, so the key in a leaked jar points straight at the buyer.
Obfuscated jars stay traceable: classes that hold a download placeholder are never string-encrypted, so the key is still readable in step 2.
Sentinel flags keys being shared (too many servers, impossible travel, a revoked key still in use, a key posted in your Discord) and offers one-click fixes you can undo.
Revoke from the dashboard, the CLI or Discord. The free Paper template re-checks every few hours and keeps running when SunLicense can't be reached.
On Standard, downloads from SunLicense carry a watermark, Whose copy is this? names the customer when you upload a leaked file, and the web patrol looks for copies offered online.

The free plan covers 3 products and 100 licenses, with no cut of your sales. See how it works for Minecraft plugins before your next release, so the next leak takes five minutes.

This article was written with the help of an AI assistant and reviewed by me before publishing.

How to protect your FiveM scripts: obfuscate Lua for free

Kasun Hapangama — Fri, 06 Nov 2026 20:52:49 +0000

Sell FiveM scripts? Then every buyer can open your .lua files and read every line. Copying your logic, removing your credits or patching out a check takes a text editor and five minutes.

Obfuscation makes that much harder: names become noise, control flow gets scrambled, and the code still runs. This guide walks through obfuscating a whole FiveM resource for free, without breaking the exports, events and NUI callbacks other resources rely on, and how to test it before you ship.

First: do you need it?

Be clear on two things before you start:

Tebex asset escrow already encrypts escrowed files. If you sell through Tebex with Cfx's asset escrow, the files it encrypts don't need obfuscation (Cfx's own FAQ says so). Obfuscation is for what escrow doesn't cover: files you keep readable with escrow_ignore that still hold logic, and resources you deliver outside escrow (other stores, commissions, private sales).
The Cfx.re forum's Releases section doesn't allow third-party obfuscation. If you post a resource there, don't obfuscate that release.

What obfuscation does: renames local variables and scrambles the structure of your code, so reading or editing it is slow and painful, while it still runs the same.

What it doesn't: stop someone determined, or stop a buyer from sharing the resource. It raises the cost of copying your work. For sharing, you need a license key per buyer (more at the end).

Step 1: Check for Lua 5.4-only syntax

This is the catch that trips most people. FiveM runs Lua 5.4 (lua54 'yes' in your manifest), but Prometheus, the Lua obfuscator used here, reads and writes Lua 5.1. Most FiveM code is 5.1-compatible and works fine. Files that use 5.4-only syntax won't parse:

5.4-only syntax	Example
Integer division	`local half = count // 2`
Bitwise operators	`flags & 4`, `x >> 1`, `~mask`, and bitwise or
Variable attributes	`local id <const> = 5`, `<close>`

Find them before you upload:

grep -rnE '//|<const>|<close>|>>|<<|[^~=<>]~[^=]|[^&]&[^&]' --include='*.lua' .

Expect a few false hits (a // inside a URL string is fine). Any file with real 5.4 syntax goes on the Exclusions list in step 4, so it ships unchanged.

Step 2: Create a free account

I build SunLicense, a licensing service for script and plugin sellers, and its free plan includes 3 obfuscation runs a month. Sign up with Google, GitHub, Discord or email. No credit card.

Step 3: Developers → Obfuscation → Lua

Open Obfuscation under Developers in the sidebar, choose Lua, then Prometheus (Lua / FiveM).

Step 4: Zip the resource and upload it

Zip the resource folder (the one with fxmanifest.lua) and drop it in. A single .lua file works too. Zips up to 50 MB.

SunLicense reads your fxmanifest.lua (or the legacy __resource.lua) and obfuscates only the scripts it lists under client_scripts, server_scripts and shared_scripts, with globs like server/*.lua expanded. Everything else ships exactly as it was.

Because string literals are kept, exports, event names and NUI callbacks keep working: nothing another resource calls by name changes.

Three settings matter:

Setting	Use
Protection preset	`Medium` (recommended). `Strong` protects more but grows and slows the code; `Weak` and `Minify` are lighter
Lua version	`Lua 5.1` for FiveM and RedM (`LuaU` is for Roblox)
Exclusions	Files to leave alone: your 5.4 files from step 1, and files buyers should edit, like `config.lua` or `locales/*.lua`

Step 5: Run it and download the result

Choose Obfuscate and watch the live log. It runs as a background task, so you can close the tab and come back; results are kept for 7 days on the History tab. Every output file is syntax-checked (compiled without being run) before you get it, so a broken file never ships silently.

You get a zip with the same layout as yours, plus a short report.

For release scripts, the CLI does the same run:

sunlicense obfuscate dist/my-resource.zip --engine prometheus -o dist/obfuscated/

Step 6: Test it on a real server

Never ship an obfuscated resource you haven't started. Ten minutes on a test server:

Drop the obfuscated folder into resources/ and ensure it. No errors in the server console or the F8 client console.
Run every command and open every menu or NUI page.
Call your exports from another resource, and trigger the events other scripts listen for.
restart the resource while players are connected.
Watch the resource monitor (resmon) for CPU time compared with the original. If a hot loop got slower, exclude that file or step down a preset.

If something fails, the console error names the file. Add it to Exclusions, or try Weak, and run again.

Obfuscation is half the job

An obfuscated resource that anyone can start is still a resource anyone can share. The other half is a license key per buyer: the server owner puts their key in server.cfg, the resource checks it on start and every few hours, and a refund on Tebex revokes it automatically. A shared key then shows up on too many servers, and you can switch off exactly one buyer.

The free FiveM resource template has all of that ready (Lua 5.4, the license check, keeps running if the license server can't be reached, and a sealed core that only opens with a valid license). For the general picture, see License keys explained.

Licensing, the Tebex integration and obfuscation are all on SunLicense's free plan, with no cut of your sales. See how it works for FiveM scripts.

This article was written with the help of an AI assistant and reviewed by me before publishing.

License keys explained: how they actually work (a beginner's guide)

Kasun Hapangama — Fri, 06 Nov 2026 20:51:08 +0000

Selling a plugin, a bot, a script or a desktop app, and not sure how license keys actually work? You're not alone. Most guides jump straight to code, and skip the part where you decide what a key should do.

This guide explains the whole system in plain words: what a key is, how it gets tied to a computer, how your app checks it (online and offline), how trials and expiry work, and what happens when you revoke one. It applies to any language and any store. At the end there's a short code example and the mistakes that hurt paying customers most.

What a license key actually is

A license key like K7QX-M2PD-9HWT-R4CN is just a random, hard-to-guess ID. On its own it means nothing. It points to a record on a license server, and that record is the truth:

who bought it (the customer),
what they bought (the product and its rules),
its status: active, suspended or revoked,
when it expires, if ever,
which machines it's activated on.

That's the key difference from the old "serial number" approach, where a key was valid if it passed a math check inside the app. Those get cracked by keygens: once someone reverse-engineers the formula, they can print infinite valid keys. A random key backed by a server can't be generated, only shared, and sharing is something the server can see and stop.

The four pieces every licensing system has

Piece	What it is	Example
Product	The thing you sell	"MyPlugin", "Acme Editor"
Policy	The rules one purchase gets	2 machines, 365 days, subscription
License	One buyer's key, issued from a policy	`K7QX-…`, active, expires 6 Nov 2027
Machine	One computer or server the license runs on	a server id, a desktop's machine id

The policy is where most of your decisions live. Change a policy's machine limit and every license on it follows, so you set the rules once instead of per buyer.

Activation and machine limits

A key that works anywhere gets shared. So your app sends two things with every check: the key, and a machine id, a stable ID for the computer or server it runs on (a random ID saved in the app's folder works well; hardware-based IDs change when someone swaps a disk).

The first time a new machine checks in, it activates: it takes one of the license's slots. With "2 machines", a buyer's laptop and desktop both work. A third computer is refused with a clear "too many machines" answer, and the buyer can free a slot (from a customer portal, a Discord bot, or by asking you) when they move to a new PC.

Game-server plugins often use an IP limit instead or as well: the key works from a limited number of network addresses, the classic "one server per purchase" rule.

Be generous. People reinstall, upgrade and move. A support ticket costs you more than one extra slot.

Checking a key: online first

Most apps check online: on startup, the app asks the license server "is this key valid on this machine?" and gets one of a handful of answers.

Answer	Means	What your app should do
Valid	Active, not expired, machine allowed	Start normally
Expired	Past its end date	Offer a renewal
Revoked / Suspended	You switched it off	Stop, show a support contact
Too many machines	The slots are full	Ask the buyer to free one
Not found	No such key	Ask them to check for typos
No answer	Network down, server error, timeout	Keep running, try again later

That last row is the one beginners get wrong. If your app stops whenever the license server can't be reached, every outage (yours, the buyer's ISP, a firewall) turns paying customers into angry ones. Some marketplaces, BuiltByBit for example, warn that a plugin which disables itself when a server is unreachable may be treated as malicious. Only stop on a clear "no".

Re-check every few hours while the app runs, too. A startup-only check never notices a key you revoked yesterday on a server that hasn't restarted in a month.

Here's the logic in JavaScript (every language looks the same):

import { SunLicense } from "sunlicense";

const client = new SunLicense({ baseUrl: "https://api.sunlicense.com", token: API_KEY });

async function checkLicense() {
  try {
    const result = await client.validate(licenseKey, { host: machineId });
    if (result.valid) return "run";
    if (result.status === 400) return "stop";   // a clear "no": revoked, expired, too many machines...
    return "run";                               // a server error is not a "no"
  } catch {
    return "run";                               // unreachable: keep running, check again later
  }
}

Offline license files

Some customers run with no internet at all. For them, a license server can export a signed license file: the license's details (key, expiry, machine limit), plus a signature made with your private key, usually Ed25519. Your app ships the matching public key and verifies the file without a network. Anyone can read the file, but changing a single character breaks the signature.

The trade-off is revocation: a file someone already has stays valid until it expires. So give files a short life (a month, say) and treat them as a fallback: check online first, and use the file only when the server can't be reached.

Trials, subscriptions and expiry

The policy's type decides how time works:

Perpetual: pay once, works forever (usually with updates for a while).
Subscription: valid until a date; renewing pushes the date forward. An expired key gets an "expired" answer, so your app can show "renew here" instead of a generic error.
Trial: a short duration (7 or 14 days) and often one machine. When it ends, the same "expired" answer becomes your upgrade prompt.

Revoking, suspending and refunds

Suspend is a pause: the key stops working until you reinstate it. Use it while you look into something.
Revoke is permanent: for a leaked key, or a buyer who charged back.
Refunds should revoke automatically. If your store sends refund webhooks (Tebex, Stripe, Lemon Squeezy and others do), connect them, or refunded buyers keep a free copy.

Because every buyer has their own key, revoking one never touches anyone else.

Where keys come from

Don't email keys by hand. Connect your store so a key is created at checkout and delivered to the buyer: by email, on a "redeem" page, or written straight into the download (BuiltByBit and Voxel Shop can do that for Minecraft plugins).

What license keys don't do

A key check is one if in your code, and anyone with a decompiler can delete it. Keys stop casual sharing and make leaks traceable; they don't stop a determined cracker. If that worries you, the next layers are obfuscation and sealing part of your code so it only runs with a valid license. I wrote those up in How to protect your plugin or app from piracy, step by step.

Build it or use a service

You can build all of this: a small API, a database of licenses, a signing key for offline files, and a dashboard to revoke from. Plenty of people do. If you'd rather not, I build SunLicense, which does the pieces above: policies with machine and IP limits, SDKs for Java, JavaScript, Python, .NET, PHP and Lua, signed offline files, store integrations that issue and revoke keys, and a Discord bot for buyers. The free plan covers 3 products and 100 licenses, with no credit card and no cut of your sales.

Writing a Minecraft plugin? The step-by-step version is How to add license keys to a Minecraft plugin in 10 minutes. For anything else, see how SunLicense works and set up your first product.

This article was written with the help of an AI assistant and reviewed by me before publishing.

How to protect your plugin or app from piracy, step by step

Kasun Hapangama — Fri, 06 Nov 2026 20:31:29 +0000

Sell a Minecraft plugin, a FiveM script, a Discord bot or a desktop app, and someone will use it without paying. Usually it isn't a skilled cracker. It's one buyer sharing their copy with five friends, or a jar reposted on a leak forum the week you launch.

You can't make piracy impossible, and trying to usually hurts paying customers more than pirates. What you can do is make sharing inconvenient, make leaks traceable, and make paying the easy option. This is the plan I'd follow, in order. Each step is worth doing on its own, so stop wherever the effort stops paying off.

Step 0: Decide what you're actually fighting

Threat	How common	What stops it
A buyer shares their copy or key	Very common	Per-buyer keys and machine limits (steps 1-2)
A jar gets reposted on a leak site	Common	Per-buyer keys, watermarks, takedowns (steps 1, 6, 8)
Someone deletes your license check	Less common, easier with AI editors	Core unlock and obfuscation (steps 4-5)
A determined cracker rewrites your code	Rare	Nothing fully. Make it slow and not worth it

Most losses sit in the first two rows, and those are the cheapest to fix.

Step 1: Give every buyer their own key, automatically

A single shared password or license file can't tell anyone apart. Give each purchase its own key, so you can see who's using what and switch off exactly one person.

Don't do it by hand. Connect your store so keys are created at checkout. On BuiltByBit, an External license key placeholder writes the buyer's key into the jar they download. Voxel Shop and SpigotMC have their own placeholders, and Tebex, Stripe, Gumroad, Lemon Squeezy and others can create a key through a webhook. Wire refunds in too, so a refunded purchase loses its key.

Step 2: Limit where a key can run

A key that works everywhere is a key that gets shared. Set a limit that fits the product:

Plugins: servers per key (1-3 is typical).
Desktop apps: machines per key (2-3 covers a laptop and a desktop).
Bots or web tools: an IP address limit.

When the limit is reached, a new machine is refused with a clear message, and the buyer can free a slot themselves. Be generous: a support ticket costs you more than one extra machine.

Step 3: Check at startup, and never take a customer down

Check the license when the app starts, then again every few hours. No need to phone home every minute. Above all, only stop on a clear "no" (revoked, suspended, expired, too many machines). If your license server can't be reached, keep running. BuiltByBit's DRM guidance says the same, and plugins that disable themselves when a server is down risk being removed. For a Minecraft plugin, I walk through this check line by line in How to add license keys to a Minecraft plugin in 10 minutes.

For customers without internet, ship a signed offline license: a file signed with a private key (Ed25519, for example) that your app verifies with the public key, and that expires on a date you set.

Step 4: Make the check hard to delete

A license check is one if statement. Anyone with a decompiler, or an AI editor, can delete it. Two things make that pointless:

Core unlock. Encrypt a small, essential piece of your code (a core class, default rules, a lookup table) and only decrypt it after a valid license check. Delete the check, and that piece is simply missing.
Tamper reports. Hash your own classes and report a modified copy with the next license check, so you know which license runs a patched build.

Step 5: Obfuscate your release builds

Rename classes and methods, encrypt strings and scramble control flow, so your check and your core are hard to find and patch. ProGuard gives a safe rename; ProGuard followed by Skidfuscator adds control flow and string encryption. Only obfuscate the build you sell, test it before upload, and keep the mapping file so you can read customers' stack traces. I wrote a step-by-step guide: How to obfuscate a Minecraft plugin.

Step 6: Watermark every download

Put something in each buyer's copy that names them: their license key in the jar, an ID in the manifest, a mark in the archive. When the jar shows up on a leak site, you know whose it was without guessing. It also deters sharing: people think twice when their copy carries their name.

Step 7: Watch for sharing

You won't spot a shared key by reading logs. Get alerts for the patterns that matter: one key on many machines at once, a key checking in from two countries an hour apart, a machine trying random keys, a revoked key still in use, a key pasted in your Discord. Then act on the real ones (a customer who travels isn't a pirate).

Step 8: Respond fast when something leaks

Find the buyer from the watermark or the key in the leaked file.
Revoke that key. Copies stop at their next check; everyone else is untouched.
Send a takedown notice (DMCA) to the site hosting it. Most marketplaces also have a DMCA form.
Revoke refunded and charged-back purchases too, or they keep a free copy.

The full walkthrough, from unzipping the leaked jar to the takedown notice: Your Minecraft plugin leaked. Here's how to find who leaked it and stop the copies.

Step 9: Make paying easier than pirating

The best anti-piracy feature is a product that's easy to buy. A fair price, a trial, fast updates, real support and a Discord. A pirate gets an old jar and no help. A customer gets the update that fixes their bug today.

The whole plan on one page

How to put it together

You can build each layer yourself: a small key server, a signing key, an obfuscation step in your build, and a dashboard to revoke from. Or use a service. I build SunLicense, which covers the list:

Step	In SunLicense	Plan
1. Per-buyer keys from your store	BuiltByBit, Voxel Shop, SpigotMC, Tebex, Stripe, Gumroad and more	Free
2. Machine and IP limits	Per policy	Free
3. Safe startup check, offline files	SDKs for Java, JavaScript, Python, .NET, PHP and Lua; signed Ed25519 files	Free
4. Core unlock and tamper reports	Seal up to 512 KB, 7 days offline grace	Free
5. Obfuscation	Maximum, ProGuard, yGuard, Skidfuscator; JavaScript, Python, Lua (FiveM)	Free (3 runs a month)
6. Watermarked downloads	The buyer's mark in each file	Standard
7. Sharing alerts	Sentinel detectors, Discord alerts	Free
8. Revoke in one click	Dashboard, CLI, Discord	Free

It's free for 3 products and 100 licenses, with no credit card and no cut of your sales. See what SunLicense covers, then work through the list, starting with step 1.

This article was written with the help of an AI assistant and reviewed by me before publishing.

How to obfuscate a Minecraft plugin (free, step by step)

Kasun Hapangama — Fri, 06 Nov 2026 20:31:21 +0000

Assume your premium plugin will be decompiled the day it goes on sale. Anyone can open the jar in a decompiler and read your code like the source, including the license check you spent an evening on.

Obfuscation won't make that impossible. It turns readable code into a puzzle, so copying your logic or patching out a check takes far more work. The catch: a careless obfuscation pass is the fastest way to ship a plugin that doesn't load. Paper and Spigot find your main class by name and call your event handlers by reflection. Rename the wrong thing and the server throws ClassNotFoundException at startup.

This guide shows two ways to do it safely: the quick way, with a free hosted obfuscator that writes the keep rules for you, and the by-hand way with ProGuard. Then a checklist to test the jar before you sell it.

What obfuscation does, and what it doesn't

It does: rename your classes, methods and fields to a, b, c, encrypt string constants, and scramble control flow. A decompiler still produces Java, but it reads like noise.

It doesn't: stop someone determined, or stop a buyer from sharing the jar. It raises the cost of reading and patching your code. For sharing you need a license key per buyer (more at the end). The two work best together: obfuscation hides the check, and the license makes a shared jar useless.

The quick way: free hosted obfuscation

I build SunLicense, a licensing service for plugin and app sellers. Its free plan includes 3 obfuscation runs a month, which covers a release or two. It runs ProGuard, yGuard and Skidfuscator on its servers, and it reads your jar to find what must keep its name, so you don't write keep rules.

Step 1: Create a free account

Step 2: Developers → Obfuscation → Java

Open Obfuscation under Developers in the sidebar and pick Java. (The same page handles JavaScript, Python and Lua for FiveM, if you sell those too.)

Step 3: Pick Maximum or ProGuard

Engine	What it does	Pick it when
Maximum (recommended)	ProGuard renames, then Skidfuscator adds control flow and string encryption	You want the strongest protection and will test the result
ProGuard	Renames classes, methods and fields	You want the safe standard, or Maximum broke something
yGuard	Renames only	You need the most compatible option
Skidfuscator	Control flow and strings, keeps names	You want flow and string protection without renaming

Start with Maximum. If your plugin leans heavily on reflection (NMS, Gson models, a command framework) and something misbehaves in testing, run the same jar again with ProGuard.

Step 4: Upload the built jar

Build the jar you actually ship (with Shadow, ./gradlew shadowJar) and drop it in. A .jar or a .zip of several jars, up to 100 MB, Java up to 25.

SunLicense reads the jar and keeps the names that must survive: the main class in plugin.yml, paper-plugin.yml or bungee.yml, velocity-plugin.json, Fabric and Forge entry points and mixins, META-INF/services, @EventHandler and @Subscribe methods, enums and serialisable types.

One detail that saves a lot of pain: if you sell on BuiltByBit or Voxel Shop with a download placeholder (a string like %%__SUNLICENSE__%% the store replaces with the buyer's key), string encryption would hide that string from the store. Classes that hold a placeholder are never string-encrypted, so key injection keeps working.

Optional: Advanced options has a Keep unrenamed list for extra packages or classes (for example com.example.api.**), and lets you add library jars you compile against if the report mentions missing classes.

Step 5: Run, then download three files

Choose Obfuscate and watch the live log. It runs as a background task, so you can close the page and come back; results are kept for 7 days and stay on the History tab. You get:

The obfuscated jar: the one you upload to your store.
The mapping file: keep it for every release. When a buyer sends a stack trace full of a.b.c, ProGuard's retrace tool turns it back into your real names.
A short report on the run, including any warnings.

Releasing often? The same run works from a release script with the CLI:

sunlicense obfuscate build/libs/MyPlugin-1.0-all.jar --profile release -o dist/

The by-hand way: ProGuard

If you'd rather run it yourself, ProGuard is the safe choice. What you must keep:

Keep	Why
The `main:` class in `plugin.yml` (and `paper-plugin.yml`, `bungee.yml`, `velocity-plugin.json`)	The server loads it by exact name
`@EventHandler` methods	Found by annotation; shrinking removes "unused" methods
`ConfigurationSerializable` classes	Saved configs store the class name
Enum `values()` / `valueOf()`	Used when reading config values back
Anything loaded by reflection	The name is a string in your code

A starting config for a shaded jar:

-injars  build/libs/MyPlugin-1.0-all.jar
-outjars build/obf/MyPlugin-1.0.jar
-libraryjars <java.home>/jmods/java.base.jmod(!**.jar;!module-info.class)
-libraryjars libs/paper-api.jar

# Plugins are loaded by reflection: don't shrink or optimise
-dontshrink
-dontoptimize
-keepattributes *Annotation*,Signature,InnerClasses,EnclosingMethod,SourceFile,LineNumberTable

-keep public class com.example.myplugin.MyPlugin { *; }
-keepclassmembers class * { @org.bukkit.event.EventHandler <methods>; }
-keep class * implements org.bukkit.configuration.serialization.ConfigurationSerializable { *; }
-keepclassmembers enum * {
    public static **[] values();
    public static ** valueOf(java.lang.String);
}

-printmapping build/obf/mapping.txt
-dontwarn

Add a -keep line for every package you reach by reflection. For more strength, run Skidfuscator after ProGuard: turn on string encryption first, test, then control flow, and test again. Exclude the class holding any store placeholder from string encryption.

Test the jar before you sell it

Never upload an obfuscated jar you haven't started. Five minutes:

Start a clean Paper server with only your plugin. No errors in the console.
Run every command, including tab completion.
Trigger your main events (join, break a block, open your GUI).
Restart the server: config and saved data load back.
Test on every server version listed on your store page.
Open the jar in a decompiler yourself and check it reads like noise.

If something fails, the error names the class. Keep that package unrenamed, or step down from Maximum to ProGuard, and run again.

Obfuscation is half the job

An obfuscated jar that anyone can run is still a jar anyone can share. The other half is one license key per buyer, checked on startup: a shared key then shows up on too many servers, and a leaked jar names its buyer. I wrote that up separately: How to add license keys to a Minecraft plugin in 10 minutes.

Licensing and obfuscation are both on SunLicense's free plan, with no cut of your sales. See how it works for Minecraft plugins.

This article was written with the help of an AI assistant and reviewed by me before publishing.

How to add license keys to a Minecraft plugin in 10 minutes

Kasun Hapangama — Fri, 06 Nov 2026 20:30:22 +0000

Selling a premium plugin without license keys? Then every copy is the same jar. One buyer can hand it to a whole network, and when it turns up on a leak site you can't tell whose copy it was.

This tutorial adds licensing to a Paper plugin in about ten minutes. Every buyer gets their own key automatically when they download from BuiltByBit, a key works on a limited number of servers, and you can switch off one leaked copy without touching anyone else. It follows BuiltByBit's DRM guidance, so it never takes a paying customer's server down.

I build SunLicense, and I'll use it as the license server here (the free plan covers 3 products). The design works the same with any licensing service.

The design, in four rules

One key per buyer, written into the jar by the store. No keys to send by hand.
A server limit per key, for example two servers per purchase.
Check on startup, re-check every few hours. No phoning home every minute.
Only stop on a clear "no". If the license server can't be reached, keep running.

Rule 4 matters most. BuiltByBit's DRM guidance warns that a plugin which disables itself whenever a server is unreachable can be treated as malicious and removed.

Step 1: Create the product and a policy (2 minutes)

Create a free account (Google, GitHub, Discord or email, no credit card), then:

Products → New product, for example "MyPlugin".
New policy: this is what one purchase gets. Set Max machines to 2. For a plugin, a machine is a server.
API keys → New key. Your plugin uses it to check licenses. Keep it out of git.

Step 2: Add the check (5 minutes)

The fastest way: start from the free Paper plugin template. It already has the SDK relocated into your package with Shadow, a console message for every result, the re-check every few hours, an offline-license fallback, and it keeps running when the server can't be reached.

Click Use this template on GitHub, then rename com.example.myplugin.
Put the API key in ~/.gradle/gradle.properties as sunlicenseApiKey=slk_....
Run ./gradlew runServer to start a local Paper server with your plugin.
Put your features in core/CoreFeatures.java. They start once the license is valid.

Adding it to an existing plugin instead? Add the Java SDK (com.sunlicense:sunlicense, current version in the docs), shade and relocate it, and run the check off the main thread:

// BuiltByBit replaces this string with the buyer's key when they download.
private static final String LICENSE_KEY = "%%__SUNLICENSE__%%";
private SunLicense client;
private String serverId;

@Override
public void onEnable() {
    client = new SunLicense.Builder()
            .baseUrl("https://api.sunlicense.com")
            .token(API_KEY)
            .timeout(Duration.ofSeconds(10))
            .build();
    try {
        serverId = serverId();
    } catch (IOException e) {
        serverId = "unknown";
    }
    // Check now, then every 6 hours, on a background thread.
    long sixHours = 20L * 60 * 60 * 6;
    getServer().getScheduler().runTaskTimerAsynchronously(this, this::checkLicense, 0L, sixHours);
    // ...start your plugin
}

private void checkLicense() {
    try {
        SunLicense.Result result = client.validate(LICENSE_KEY, Map.of("host", serverId));
        if (result.isValid()) {
            return;
        }
        if (result.getStatus() == 400) {
            // A clear "no": revoked, suspended, expired or too many servers.
            getLogger().severe("This copy is not licensed. Contact the author.");
            getServer().getScheduler().runTask(this,
                    () -> getServer().getPluginManager().disablePlugin(this));
        } else {
            // A server error is not a "no".
            getLogger().warning("License server answered " + result.getStatus() + ", running anyway.");
        }
    } catch (SunLicense.SunLicenseException e) {
        // Can't reach the license server: keep running, check again later.
        getLogger().warning("License server unreachable, running anyway.");
    }
}

// A random id saved in the plugin folder, so each server counts once.
private String serverId() throws IOException {
    Path file = getDataFolder().toPath().resolve(".server-id");
    if (Files.isRegularFile(file)) {
        return Files.readString(file).trim();
    }
    String id = UUID.randomUUID().toString();
    Files.createDirectories(file.getParent());
    Files.writeString(file, id);
    return id;
}

Two details worth copying: only HTTP 400 counts as a "no" (a 5xx or a timeout never stops a server), and the server id is a stable random id rather than the IP, which is often blank on hosted servers.

Step 3: Let BuiltByBit deliver the keys (2 minutes)

In SunLicense: Integrations → BuiltByBit → Connect. Map your resource ID (the number at the end of your resource URL) to the policy. SunLicense creates the secret and shows the hook URL.
On BuiltByBit: Creator dashboard → Placeholders → Create placeholder:
- Placeholder: %%__SUNLICENSE__%%
- Type: External license key
- URL and secret: from step 1
Apply it to your resource and publish an update. Placeholders only apply to files uploaded after they exist.

Now each download contains that buyer's own key, the same one every time they re-download. Selling on Voxel Shop or SpigotMC instead? Both have their own placeholder integration on the same page.

Step 4: Test it like a buyer (1 minute)

Download your resource from BuiltByBit once and check the jar contains a key, not the placeholder string.
Start a server: the console says the license is valid.
Start a third server with the same key: it's refused (too many servers).
Revoke the license in the dashboard: at the next check, the plugin stops with your message.
Block the license server (for example in your hosts file) and restart: the plugin keeps running.

What you get

A shared key gets refused past the server limit.
A leaked jar names its buyer. The license is named after their BuiltByBit user ID, so you revoke that one license and every copy of that jar stops at its next check.
Paying customers never notice: one check on startup, a quiet re-check, and it keeps running if your license server has a bad day.

Going further

Offline licenses: a signed file for servers without internet access.
Seal a core: with the template, ./gradlew build -PsunlicenseProduct=<code> seals a part of your plugin so only a valid license unseals it. Deleting the check then doesn't help a pirate.
Obfuscate the release jar: see How to obfuscate a Minecraft plugin.
Let your coding agent do it: the product's Setup tab has a prompt for Claude Code, Cursor or Codex that adds all of this to your project and proves it works with a test license.

Licensing, the BuiltByBit integration and obfuscation are all on SunLicense's free plan, with no cut of your sales. See how it works for Minecraft plugins and protect your next release.

This article was written with the help of an AI assistant and reviewed by me before publishing.

Stop Shipping Software Without a License System — Meet SunLicense

Kasun Hapangama — Wed, 10 Jun 2026 18:26:48 +0000

If you've ever shipped a software product — a Minecraft plugin, a Discord bot, a Java library, anything paid — you know the feeling.

Someone reposts your download link. A customer's key gets leaked. You have no way to invalidate it, no idea how many installs are out there, and no system to do anything about it.

License management is one of those unsexy problems every indie dev eventually hits. Most either skip it entirely, roll a janky home-baked solution, or find enterprise tools that cost more per month than the product earns.

SunLicense is a different answer — built by an indie dev, for indie devs, priced as a one-time $14.99.

Disclosure: I'm Kasun Hapangama, the creator of SunLicense. Stats and review excerpts are pulled directly from the BuiltByBit listing.

What Is SunLicense?

SunLicense is a self-hosted license management system that ships with:

A web admin dashboard
A customer-facing dashboard (with Discord OAuth2 login)
A Discord bot for automated license workflows
A RESTful license API
A Java API wrapper
BuiltByBit marketplace integration for fully automated license issuance

It's currently at v1.2.4, with 11 updates since launch in January 2025, 212 purchases, and a 5.0 average rating across 16 reviews on BuiltByBit.

How It Works

The core model is dead simple — intentionally so.

1. You create a license key (dashboard or API)
2. The user enters the key in your product
3. Your product calls the SunLicense validation endpoint
4. The server applies your rules → grants or denies access

Rules you can configure per license:

Expiry dates
Device (HWID) restrictions
IP restrictions / blacklists
Temporary licenses
Max activations

Integrating Into Your Product

Java (using the official API wrapper)

// Initialize the client
SunLicense client = new SunLicenseClient(
    "https://your-sunlicense-host.com",
    "your-product-secret-key"
);

// Validate at startup
ValidationResult result = client.validate(
    userInputKey,
    HardwareID.generate() // auto HWID binding
);

if (!result.isValid()) {
    System.out.println("License invalid: " + result.getReason());
    System.exit(1);
}

// License valid — continue loading your product

Other Languages (REST API)

POST /api/v1/license/validate
Content-Type: application/json

{
  "key": "XXXX-XXXX-XXXX-XXXX",
  "hwid": "generated-hardware-id",
  "product_id": "your-product-id"
}

Response:

{
  "valid": true,
  "expires_at": "2026-12-31T00:00:00Z",
  "message": "License validated successfully"
}

Support guides exist for PHP, Python, JavaScript, Lua, and more — so you're not starting from scratch regardless of your stack.

Feature Breakdown

Core

Feature	Status
Web Admin Dashboard	✅
Customer Dashboard (Discord OAuth2)	✅ New in 1.2
Discord Bot Integration	✅
RESTful License API	✅
Java API Wrapper	✅
Temporary Licenses	✅
IP Restrictions	✅
HWID Restrictions	✅
Unlimited Products & Licenses	✅
Graphs & Analytics	✅
Dark Theme	✅

Automation

Feature	Status
Auto License Creation via BuiltByBit Purchase	✅ New in 1.1
Auto License Creation via Discord Role	✅ New in 1.1
Product Discord Role on License Claim	✅ New in 1.1
DM Discord Commands	✅ New in 1.1
Custom Discord Embeds	✅ New in 1.1
Blacklists (IP / HWID)	✅ New in 1.1

Security & Ops

Feature	Status
Secure Developer API	✅ New in 1.2
Disaster Mode (Panic Mode)	✅ New in 1.2
Automated + Manual Backups	✅ New in 1.2
System Health Checks	✅
Blacklisting	✅

Platform Support

SunLicense ships with integration guides for:

Minecraft — Plugins, Mods, Server Software
Discord Bots
FiveM Projects (added in 1.1)
Java Projects
PHP Projects
Python Projects
JavaScript Projects
Lua Projects

Infrastructure: runs on ARM and x86, supports Pterodactyl Panel (a Pterodactyl Egg is included), and managed hosting is available if you'd rather not self-host.

Who Should Be Using This

Marketplace sellers (BuiltByBit, Spigot, etc.)

The BuiltByBit automation is the headline feature. When someone buys your resource, SunLicense auto-generates their key and optionally assigns a Discord role — zero manual steps. If you're actively selling on a marketplace and handling license requests by hand, this alone pays for itself.

Discord bot developers

The Discord-native workflow is genuinely polished. Customers can claim and check licenses entirely via DM commands. Role-gated access works automatically on claim. Custom embed support means it fits your branding without looking like someone else's bot.

Java / backend developers

The Java API wrapper is well-maintained, there's a sample project in the docs, and HWID + IP binding gives you real protection for desktop software without running your own validation infrastructure.

Small studios with multiple products

Unlimited products and licenses out of the box. If you're at three or four products and still handling key distribution manually over Discord — this is the inflection point where a system like this pays for itself in hours saved per week.

The Honest Take

No tool is perfect, and the reviews are candid about where SunLicense has room to grow.

The setup process has a learning curve, especially outside the Java ecosystem. One reviewer noted:

"Not being able to configure things outside the Java experience makes it harder than it needs to be sometimes."

This is fair feedback. The creator has acknowledged it publicly and is active on the Discord server taking suggestions.

The flip side: 11 updates since January 2025, covering things users actually asked for — customer dashboards, automated backups, FiveM support, the secure developer API. That pace of iteration matters a lot when your product's license validation depends on a tool staying maintained.

One other thing worth knowing: this is a self-hosted system. You're responsible for running the server, or you pay for managed hosting. If zero-ops is a hard requirement, factor that into your evaluation.

What Users Are Saying

"The dashboard is intuitive, the automation works flawlessly, and every feature feels like it was built with real developers' needs in mind. It's rare to find a product that combines such a smooth user experience with this level of power and reliability."
— gOOvER, ★★★★★

"By far the best License Management system. The owner even helped me in a private voice call to set everything up — 10/10."
— xByNovaTV, ★★★★★

"It's a solid and promising product. The Discord bot is super helpful. You can tell there's real passion behind it. Setup can be a pain outside Java, but despite those bumps, it's still a great tool overall."
— bestiebeate, ★★★★☆

"This is the first and probably last license system I have to buy."
— workattack, ★★★★★

Pricing

Tier	Price
Base License	$14.99 one-time
Enhanced Support (install & setup)	+$20.00
Source Code	+$99.00
Support Duration	Lifetime

Bundles are also available:

SunLicense Bundle — Total Protection & Control for Your Software (~$25.48, was $29.98)
SunDevs Developer Bundle — All SunDevs products (~$47.96, was $59.96)

Links

Built and maintained by Kasun Hapangama @ SunDevs · Sri Lanka