Minecraft plugins

Your plugin is on a leak forum by Friday.

You spent months on a Paper plugin, sold it to eleven servers, and the twelfth downloaded it from somewhere else. A jar is a file, and a file gets passed around. What you can decide is whether it does anything useful once it has been.

The part nobody warns you about

It is not the leak. It is what the leak does to you: you stop shipping, because every update is more work handed to somebody who did not pay. Plenty of good plugins die at exactly that point, and the author calls it losing interest.

What Bloom does about it

A check on enable

Your plugin calls the validation endpoint when it loads, with the license key from config.yml. Refused keys come back with a reason, so you can log something a server owner can act on rather than a stack trace.

Tied to one server

Send a hardware id with the check and the license locks to the first machine that used it. The same key on a second box is refused. Leave the field out and the key works anywhere, which is the right call for a network buying for ten servers.

Revoke without a release

A chargeback, a resale, a shared key. Block the license from the panel and the next check fails. No new jar, and nobody has to update anything.

Where your customers already are

Your buyers are in your Discord. So is the bot: issue a license, look one up, or block one without opening a browser, plus a store your members can buy from.

The model that fits

License key in config

Plugins already ship with a config file, and server owners already expect to paste a key into one. It is the model that asks the least of them.

You deliver a license key to each customer (by purchase, email, or login). The app validates the key against Bloom Cloud and activates it on their machine. Simplest for products that already sell keys.

The integration is one HTTPS call, and the panel hands you the code for it in JavaScript, Python, Go, Java, C# or PHP. There is nothing to install.

What people ask

What happens if Bloom is down when a server restarts?
That is your decision, in your code. Most plugins treat a failed request as valid and a refusal as invalid, so an outage on our side never takes down somebody who paid. The status page is public.
Can somebody just delete the check from the jar?
Somebody determined can, and any honest licensing product will tell you the same. What licensing stops is the casual copy, which is nearly all of it, and it gives you a way to cut off the one account that is reselling.
Does it work with Paper, Spigot, Folia, Velocity?
Bloom does not know or care what your software is. It is an HTTPS call, so anything that can make one works, on any Java version you are targeting.

Something else on your mind?

Ask before you sign up. It reaches a person, and you get an answer by email.

Ask us

What Bloom does not do here

Bloom does not obfuscate or protect your jar itself, and there is no anti-tamper agent to install. It licenses the plugin; hiding the bytecode is a separate problem, if you have one.

Bloom does not care what it is

The same account, the same call, whatever you happen to have built.