Sign in to issue and manage licenses.
The master key generated when Gorilla License Studio was installed. Use this to sign in the first time, before any user accounts exist.
Issues and tracks licenses validated by client installs (G-Hub and other Gorilla applications) via POST /api/v1/validate.
POST /api/v1/validate
Contact email(s) here are used for expiry warnings and license issue/revoke/enable notifications, alongside the notification email(s) configured in the Settings tab.
The setup key is what a new install of any Gorilla app must be given (alongside the organization name) before it can fetch this client's licence automatically. Without it, anyone who guessed the organization name could claim their licence. Existing installs are unaffected — they already hold a key and never use this again.
The catalog of product codes offered on the Issue License dropdown. A product can only be deleted once no active (non-revoked, non-expired) license uses it.
Every license, organization, and user change - logins, and rejected phone-home attempts. Older entries are purged automatically on a rolling basis (retention period set in the Settings tab).
One row per organization — how many licenses they've been issued (any status), and how many distinct PCs and named users are currently active across them. Export the full detail (every license, PC, and user) to a spreadsheet with the button below.
Pick a client (and optionally one product) to see every license they hold, seat usage, and every PC and named user activated against it - export it to a spreadsheet or a branded PDF, or email the PDF straight to the client.
Automatically generates the Client License Report (Reports tab) on a recurring schedule and emails the PDF - to Mojola management, the client, or both. On a send failure, this retries automatically, and after 3 failed attempts in a row it emails Mojola management to flag it.
Anyone here can sign in and manage licenses. Only admins can manage this list. Passwords are never shown once set - reset them instead if someone forgets theirs.
Each role controls which tabs an account sees and what it can do there. Every account (see the Users tab) has exactly one role.
Where license/organization/product activity gets emailed - new clients, issue/revoke/enable, organization disable, and expiry warnings, alongside each organization's own contact address(es) and a license's one-off contact email.
How many days before a license expires (or after, if already expired) to send the warning email above, and how often to check.
How the emails above actually get sent. Leave a field blank to fall back to the appsettings.json Smtp: config, if one was set during install.
How long audit entries are kept before being purged automatically, and how many rows the Audit Log tab shows by default (a specific export or filter can still ask for more, up to 10000).
Signs a user out automatically after this many minutes of no activity in the browser.
When on, a new install must present its client's setup key (see the Organizations tab) to fetch a licence automatically — the organization name alone isn't enough. Only turn this off temporarily if a site is still running an app version built before setup keys existed, and turn it back on once it's updated.
The break-glass key (X-Admin-Key) used by scripts, and to sign in when no account can. It now lives in the database and can be rotated here — no config file edit or service restart. Rotating it stops the old key working immediately. It's shown once, when generated, and never again.
X-Admin-Key
Takes a safe online copy of the licence database on a schedule, keeping the most recent few and deleting older ones. Leave the folder blank to store them in a Backups folder next to the database itself — but a different drive or a network path is safer, since a backup beside the original doesn't survive losing that disk.
Backups
Permanently removes every organization, license (and its activations), and audit log entry — for clearing out test/demo data before a real go-live. Users, the Products catalog, and these Settings are not affected. This cannot be undone — back up the server's database file first if there's any doubt.
Reserved super-user usernames for other Gorilla apps (e.g. "G-HUBSUPERUSER", "G-TISUPERUSER") — that app calls G-LS to verify the password on login instead of storing it in its own database. One row per app, so rotating or locking one out never affects the others. Always stored/shown uppercase, regardless of how it's typed. Passwords are never shown once set — rotate them instead if one needs to change.
Browsing the server's own filesystem — this is where G-LS itself runs, which may not be this computer.