Every plugin developer who starts selling eventually has the same thought: how hard can licensing be? A database table of keys, an endpoint that says yes or no, a check in onEnable(). A weekend, tops.
The weekend version is genuinely easy to build. The problem is everything it quietly doesn’t do. Here’s an honest look at what a licensing system needs once real customers (and real pirates) are involved, and when building your own is still the right call.
The weekend version
Most homemade systems start out looking something like this:
- A small web server with a
/validateendpoint. - A table of license keys.
- The endpoint looks up the key and returns
valid: trueorvalid: false. - The plugin calls the endpoint on startup and disables itself on
false.
It works in testing, it works for your first few customers, and it will stop almost nobody.
Where homemade systems break
1. A plain “yes” is easy to fake
If your server replies with unsigned JSON, anyone can impersonate it. Point the plugin’s hostname at 127.0.0.1 in the hosts file, run a tiny local server that always answers valid: true, and your license check passes for every key, forever. No bytecode editing required.
The fix is to sign every response with a private key only your server holds, and verify the signature in the plugin with the matching public key. A forged response fails verification.
Signing on its own isn’t enough, though. An attacker can record one genuine “valid” response and play it back. So each request also needs a nonce: a random value the plugin generates, the server includes in its signed response, and the plugin checks on the way back. A replayed response carries the wrong nonce and gets rejected.
This is the part most homemade systems skip, and it’s the part that decides whether your check means anything. (It’s also exactly what MC License does on every check.)
It’s worth being honest about the limit here: no licensing system stops a determined attacker who decompiles your jar and deletes the check. What licensing does is make the easy bypasses fail, turning “anyone can share this” into “someone has to put real work into cracking it.”
2. One key, fifty servers
A valid key is valid no matter who’s holding it. Without limits, one buyer can post their key in a Discord server and every server that uses it passes validation.
Stopping that means tracking which servers are currently using each key, deciding what counts as “active,” expiring stale entries, and rejecting validations over a limit. You’ll also want per-license overrides for customers with legitimate multi-server setups. We wrote a whole post on how concurrent limits and IP restrictions stop key sharing. It’s a feature in its own right, not a column in a table.
3. Your uptime becomes your customers’ uptime
The moment your plugin checks a license on startup, your license server is a dependency of every server running your plugin. If your VPS reboots, your domain lapses, or your database falls over at 3am, customers’ servers are affected.
Getting this right means:
- Doing the check off the main thread, so a slow response can’t freeze server startup. (Here’s why that matters and how to do it.)
- Setting timeouts on every request.
- Deciding what happens when the check can’t complete rather than comes back invalid, so an outage on your end doesn’t take every legitimate customer offline.
- Actually keeping the server up, monitored, backed up and patched, indefinitely.
4. Getting keys to buyers
Someone buys your plugin at 2am. Who creates their key?
In the weekend version, you do, when you wake up. Automating it means integrating with every marketplace you sell on, and they all work differently. Tebex sends purchase webhooks, so you email the key. BuiltByBit can request a key at download time and insert it into the jar. Voxel Shop (Polymart) inserts its own placeholders and expects you to verify purchases against its API. Each integration has its own auth, its own edge cases and its own ways to change under you.
(If you’re curious what that looks like in practice, see how it works on Tebex, BuiltByBit and Voxel Shop.)
5. Everything around the check
Once customers exist, you need tools that aren’t about validation at all:
- A way to look up, disable, extend and delete keys without opening a database shell.
- Expiry dates for rentals, trials and subscriptions.
- A way for customers to check their own license status instead of opening a ticket.
- Logs of failed validations, so you can spot sharing or a broken release.
- Rate limiting, so nobody can brute-force your key space through your own endpoint.
- If you have a support team, access for them that isn’t your admin password.
None of this is hard on its own. Together, it’s a second product you now maintain alongside your actual plugins.
When building your own makes sense
Buying isn’t always the right answer. Building your own is reasonable when:
- You need something unusual: offline licensing for air-gapped servers, entitlements tied to your own account system, or checks woven deep into custom infrastructure.
- You already run infrastructure: a studio with servers, monitoring and on-call already in place adds a licensing service at a much lower marginal cost.
- It’s the point: building a licensing server is a genuinely good learning project, and there’s nothing wrong with doing it for that reason.
If you do build it, the minimum bar is: signed responses, a per-request nonce, async checks with timeouts, a grace path for network failures, server or IP limits, rate limiting, and logs you actually look at.
When it doesn’t
For most solo developers and small teams, the maths is simple. Hosting alone for a homemade system tends to cost about as much as a hosted plan, before you count a single hour of your time building, securing and maintaining it. Every one of those hours is an hour not spent on the plugins that actually earn you money.
That’s the gap MC License exists to fill: signed and nonce-checked validation, concurrent server limits, expiry, analytics, marketplace automation and collaborators, integrated with one dependency and one check in onEnable().