License and activation
Configure customer authorization without exposing keys or installation identity.
Access links and activation instructions are provided to licensed buyers. Follow the instructions supplied with the official distribution. A config file or dashboard link token does not by itself establish a verified license.
Licensed JAR behavior
Before worlds, plugins, or the game port open, the JAR requests signed authorization. Startup stops without valid proof. During operation, authorization is renewed. A network failure is not immediately treated as revocation, but an expired lease can request a normal shutdown.
This depends on the customer release service. Local source inspection does not verify today’s production backend. If activation is unavailable for your purchase, use the customer channel you were given.
Store the key privately
The implementation accepts NUSA_LICENSE_KEY in the server process environment or license-key in nusa-license.properties. Without another key source, a missing file is created with a placeholder and startup stops. Enter your own key only in the private environment following customer instructions.
Priority is the nusa.license system property, then environment, then file. Avoid JVM arguments for keys because process listings can expose them. A stale higher-priority value can override a corrected file.
Protect file permissions and private backups. Never upload license/bridge files or installation identity to public support. Safemode does not disable license enforcement.
Moving to another machine
Stop the old server and back it up. Changes to the host, OS, or service account may change installation identity. Follow the customer procedure for updating a device binding when required. Do not bypass authorization or run additional copies without the corresponding entitlement.
For failures, check system time and outbound HTTPS, then send a redacted support report with the version and relevant fixed error message.