Licensing

Editions

Janus Edge runs without a key as the Community edition: 25 active users, one node, guardrails observe-only, one identity provider. Business keys add seats, high availability, SCIM, LDAP, multiple identity providers, guardrail enforcement, scheduled reports, troubleshooting captures, model fallbacks, email alerting, the Janus FIPS edition and the STIG configuration profile. Audit export (CSV) is available on every edition and in every license state. Enterprise keys are issued per agreement and may be perpetual or air-gapped.

A key is a signed JANUS-LICENSE-1 string verified against public keys embedded in the binary. Nothing phones home: an air-gapped gateway is fully licensed with just the file.

What a Business key unlocks

Every Business feature is a control that is already in the product; Community shows it grayed out with a one-line reason, and the API answers 402 feature_not_licensed if it is called anyway. Reads are never gated, and most things configured before a downgrade keep running — only the enabling write is refused. The exception is sign-in: without a valid key that includes them, sign-in through additional identity providers and LDAP stops (Janus-account passwords and the environment-configured provider keep working). A saved Chat access restriction keeps applying on every edition; only saving a new or changed one needs Business.

Guardrails enforce: redact and block modes on security policies (observe is Community; Child Safety blocks on every edition). Request capture: turning troubleshooting recording on. Email alerts: the email channel on an alert (in-app and webhook are Community). Model fallbacks: a fallback model on a managed model. Load balancing: a managed model with more than one model, or a balancing policy other than failover. Chat access: limiting Janus Chat to chosen users, groups or teams (Administration → Chat → Who can use Chat). Scheduled reports, SCIM provisioning, multiple identity providers, LDAP directory sign-in and more than one node are described on their own pages. The FIPS edition and the STIG profile check the key at startup instead: they need a verified Business, Enterprise or trial key, and keep running when it expires.

Seats

A seat is an active user: anyone who signed in or made a request in the last 30 days. Disabled accounts do not hold a seat. A new person takes a seat at their first sign-in — including accounts created in advance by SCIM, the directory or Administration → People. When every seat is used, a new person cannot complete their first sign-in; everyone already active is unaffected, and administrators can always sign in. Adding a Janus account under Administration → People → Add user, or turning a disabled account back on (on its profile or through SCIM), is refused the same way (402 license.seats_exhausted; SCIM answers 403). SCIM provisioning itself never fails on seats.

Business seats are bought as a pool at janusedge.com and split into one key per gateway or site from the portal; each gateway enforces only its own key.

Expiry never disrupts work

Thirty days before expiry the shell shows a notice. After expiry there is a grace period (normally 30 days) in which nothing changes. After the grace period the gateway is restricted: everything already configured keeps running — proxying, every configured sign-in (SSO providers, LDAP, Janus accounts), SCIM sync, guardrails, quotas, a Chat access restriction, reports, HA — but creating new items is paused: tokens, service tokens, upstreams, managed models, routers, quotas, rate limits, policy rules, teams, groups, grants, security policies, policy bindings, term lists, alerts, reports, report schedules, SCIM tokens and Janus accounts. Edits and deletes still work: deleting is never paused, so you can remove an LDAP directory or an extra sign-in provider after a downgrade. Rotating a SCIM token counts as creating one. The API returns 402 with code license.required. An installed key that fails verification is treated the same way.

Enabling a feature the edition does not include returns 402 with code license.feature_not_licensed. A feature that is already on keeps working when the key lapses, including sign-in through additional identity providers, LDAP directory sign-in and a saved Chat access restriction. After the grace period you cannot add a provider or change who may use Chat until a key is installed. A key that fails verification includes no features, so additional providers and LDAP stop until a valid key is installed: keep a Janus-account password for at least one administrator. A saved Chat access restriction keeps running after a downgrade; you can lift it on Administration → Chat → Who can use Chat (Let everyone use Chat).

Installing a key

Admin → Settings → License & updates: paste the key exactly as downloaded from the portal and choose Install. The key is verified before it is stored and takes effect immediately on this node; other nodes pick it up within an hour or on restart.

Automatic renewal and sync is off by default. The simplest setup: paste the activation code from the janusedge.com portal (it starts with JANUS-ACTIVATION-1 and carries both the license and its sync token) into Admin → Settings → License & updates → Install a key, tick Automatically renew and sync, and install. Lost the code? Use New activation code on the key in the portal; the key and seats stay the same. Alternatively enter the raw sync token under Automatic renewal and sync, save, and use Sync now. Saving a token or installing an online key never enables sync by itself. This retrieves renewed signed licenses, not software updates. Blank tokens preserve the stored credential; Clear stored sync token removes it. JANUS_LICENSE_SYNC and JANUS_LICENSE_SYNC_TOKEN pin their respective settings when supplied in the environment. Offline mode prevents remote sync. File-backed keys are not synchronized or overwritten; deliberately remove the file configuration, restart and install a database key before opting in. Renewal warnings are suppressed only while a successful renewal confirmation is fresh; expiry and grace details remain visible.

Copy the raw Sync token from the portal. A complete license_id.token credential is also accepted only for the installed license; do not paste Authorization or Bearer header text. A revoked service response preserves signed rights and keeps a warning visible while sync continues. Only a newer same-identity signed license plus fresh higher-generation subscription evidence can automatically recover. For legacy servers without revocation freshness, obtain and manually install a verified replacement.

For deployments managed as configuration, set JANUS_LICENSE_FILE to a path containing the key. A file, when present, takes precedence over a key installed from the UI. Removing the UI key returns the gateway to Community limits without deleting anything.

Nodes and high availability

A node is one running gateway process. Every process heartbeats a row in the database; Admin → Settings → License & updates shows how many are live against what the key covers. Community covers one node. Running more than the key covers is a warning in the log and on the card — nothing is refused and no traffic is dropped, because a scale-up during an incident is exactly when you do not want licensing in the way. Add nodes at janusedge.com or scale down to clear it.

Everything a sign-in needs lives in the database: sessions, OIDC state, the pending step between password and authenticator code. Two or more replicas behind one Service work without sticky sessions; a person can enter their password on one pod and their code on another. Rate limits divide by the live node count automatically. The Helm chart defaults to two replicas with a PodDisruptionBudget and anti-affinity; SQLite mode is single-writer and stays at one.

Update check

Off by default. Set JANUS_UPDATE_CHECK=true and the gateway asks janusedge.com once a day for the latest release, sending only the running version, the edition and this gateway’s instance id. The answer (a newer version, release notes, or an advisory) is shown under Administration → Settings → License & updates → Updates and nowhere else; nothing is downloaded or changed. JANUS_OFFLINE=true forces it off for air-gapped deployments.

Perpetual keys and upgrades

A perpetual key carries a maintenance date. Any release published on or before that date runs forever. A newer release checks the key before touching the database and exits with a clear message, so the previous version restarts cleanly. Renewing maintenance at the portal issues a key with a later date.