🧩Several Jars, One License

Ship a lobby plugin and a game plugin under one product and one license key, and let each server pull the jar it needs.

A network plugin is often not one jar. A bedwars product ships a lobby plugin and a game plugin. A survival product might ship a proxy jar and a backend jar. An add-on pack might ship four.

Before, each of those needed its own product and its own key, so a customer who bought "the plugin" ended up holding three unrelated licenses and you answered three support tickets. Now one product can hold several jars, one license covers all of them, and each server names the one it wants.

Naming your jars

A jar name is a short label you choose: lobby, game, proxy, backend. Lowercase letters, digits, ., - and _.

Upload one build per jar: Products, your product, Upload jar, and set Jar name. The field suggests the names you have already used, so you do not have to remember how you spelled it last time. Leave it empty for a product that ships a single jar, which is what every existing product does.

Each jar keeps its own versions and its own stable and beta channels. Promoting a lobby build never touches game.

Uploading by API

The dashboard field is labelled Jar name, but the form field on the API is variant, the same word the loader config uses. Send anything else and the upload silently lands as the product's single unnamed jar instead of the one you meant:

curl -sSf -X POST "https://license.ohalee.com/api/dashboard/products/bedwars/payload" \
  -H "Authorization: Bearer $OBSIDIAN_API_KEY" \
  -F "variant=game" \
  -F "version=1.4.0" \
  -F "channel=stable" \
  -F "jar=@build/libs/bedwars-game-payload.jar"

Check the result with obsidian_list_versions, or Products, your product, Versions. Each row shows the variant it was filed under, so a typo is obvious immediately.

Picking a jar on the customer's side

Paper config.yml:

serverUrl: "https://license.ohalee.com"
licenseKey: "OBS-XXXX-XXXX-XXXX-XXXX"
productId: "bedwars"
serverPublicKey: "..."
variant: "game"        # this server runs the game jar

Velocity config.properties:

productId=bedwars
variant=lobby

Plain Java:

ObsidianLoader.builder()
        .productId("bedwars")
        .variant("worker")
        ...

License check (the other mode) does not need this: it verifies a license and does not download anything, so there is no jar to choose.

What the customer gets

The same license key, on every server. A bedwars customer puts one key in their lobby servers with variant: lobby, and the same key in their game servers with variant: game.

Seats count across all of it, because seats are per machine, not per jar. A customer running one lobby and three game servers uses four seats. Size the license accordingly.

How many jars you can ship

Capped per plan, because it is the feature that turns one product into a whole suite:

Plan	Jars per product
Free and mid plans	1
Top plan	Unlimited

Only a new jar name counts against the limit. Re-uploading an existing one is just a new version and is always allowed, whatever your plan.

Operators self-hosting the platform set this per plan themselves, under Plans, maxJarsPerProduct. -1 means unlimited.

If a loader asks for the wrong jar

The denial says what is actually available rather than just failing:

this product has no jar called "lobbby". Available: game, lobby

And if a product ships several jars but a loader names none:

this product ships several jars, set "variant" in your loader config to one of: game, lobby

Existing products keep working

A product that shipped a single jar before this feature keeps serving it to every loader, whether or not the loader knows about jar names. Nothing to migrate and no config to update.

If you later name your only jar something (say you upload game and never had a default), loaders that name nothing still get it: one jar is unambiguous. It is only ambiguous once you have two.