Licensing & editions

Taranac ships as a single product with two editions. Community is the free core — the complete AAA and NAC platform, TACACS+, RADIUS, 802.1X, policies, devices, users, logging, captive portal — with no usage caps and no metering: unlimited devices, users, groups, rules and policies. Pro unlocks feature-gated capabilities on top of that same core; today the only Pro feature is high availability. Pro is turned on by uploading an offline, Ed25519-signed license file (.lic) that Taranac verifies locally — there is no phone-home, no online activation, and no hardware fingerprinting. The Community core runs identically whether a license is present, absent, expired or invalid; a licensing problem can only ever stand down a Pro feature, never break authentication. This page covers the two editions, what a license is, how to find your installation ID, how to obtain and install a .lic, how to confirm it is active, and how licensing works across an HA cluster.

	Community	Pro
AAA (TACACS+ / RADIUS)	Full	Full
NAC / 802.1X (PEAP / MAB / EAP-TLS)	Full	Full
Devices, users, groups, policies, rules	Unlimited	Unlimited
Logging, audit, alerts, backups, captive portal	Full	Full
High availability (clustering)	—	Included
License file required	No	Yes (a signed .lic)

There are no scale limits and no usage metering in either edition. Taranac gates features, not volume. The single numeric entitlement a license carries is max_nodes — the size cap for an HA cluster, itself a feature dimension, not a device or user count. If you run a single Taranac node for AAA and NAC, you never need a license.

Concretely: without a valid license the product reports edition: community, an empty feature list and max_nodes: 1 — exactly what a single-node install needs, and no capability anywhere in the product is withheld. As of 1.2.8 there is exactly one feature string the code ever checks, ha; every other capability — NCM / Configuration Tracker, collectors, captive portal, Taranac MFA, reports, backups — is unconditional.

A license is a self-contained .lic file: human-readable JSON carrying a payload of entitlements plus a detached Ed25519 signature over that payload. Taranac verifies it entirely offline, against a signing public key baked into the product — nothing leaves your install. This matters for the target audience: air-gapped and isolated NAC deployments that reject outbound calls.

The outer envelope has four fields — payload, signature (base64 Ed25519 over the payload’s canonical bytes), key_id (which signing key was used) and alg, which must be Ed25519. Anything else in the envelope is rejected. The signature covers a pinned canonicalization of the payload — UTF-8, object keys sorted, no insignificant whitespace — so signer and verifier agree byte-for-byte.

The payload is the complete set of claims; there are no others:

Field	What it is
schema_version	format version (1 today)
license_id	the license’s unique id, shown in the UI and quoted in support
issued_to.org / .contact_email / .customer_id	who it was issued to (org and email are displayed; customer_id is internal)
issued_at	UTC issue timestamp
bound_to	the installation ID this file is valid for
entitlements.edition	always pro — the only value the format accepts
entitlements.features	the allow-list of capability strings; today only ha means anything
entitlements.max_nodes	the HA cluster cap (integer ≥ 1, default 1)
support.expires_at	UTC, or null for a permanent-only license
support.level	informational label
notes	optional free text

Unknown top-level payload fields are tolerated, so a newer license still verifies on an older build. Unknown keys inside entitlements are not: a file carrying an entitlement dimension your build does not know about is rejected outright as bad_payload. In practice that only matters if a future release adds a numeric entitlement — until then, features (an allow-list) is how the format grows.

A license carries two things that live by different rules:

Axis	Field	Expires?	Effect of expiry
Functionality	entitlements (features, max_nodes)	Never	— the grant is permanent
Support	support.expires_at	Yes	Warning only — nothing functional changes

This is the most important thing to understand about Taranac licensing: entitlements are permanent, support is time-boxed, and the two are independent. A license that grants ["ha"] grants HA forever. The support window is a purely commercial signal — when it lapses, the product surfaces a “support expired” banner and keeps every feature running. A license with no active support at all (support.expires_at: null) is a valid, permanent grant.

Integrity comes from the signature, not from secrecy or from any network check. Tampering with the payload — changing max_nodes, adding a feature, moving the expiry — invalidates the signature, and Taranac falls back to Community. The product ships a small trust map of key_id → public key (the production key is taranac-2026), and key rotation is additive: a new signing key is added under a new id, never swapped in place, so licenses already in the field keep verifying against the key that signed them. The matching private keys exist only with TaranacLabs, offline, and are never shipped — there is no signer inside the product and no way to mint a license from an install.

To stop one license file being copied onto an unrelated install, every .lic is bound to a single installation. That binding target is the installation ID — a random UUID Taranac generates once at first boot and stores immutably.

• Where to find it. Settings → System → Licensing (with a copy button), or from the install directory on a Taranac node:

  ./taranac installation-id

  The wrapper refuses this command on a witness or standalone collector host — those have no database and no identity of their own; run it on a Taranac node.

• It is stable across VM migration. The ID is a persisted random UUID, deliberately not a hardware fingerprint. Fingerprints (MAC, CPU, machine-id) break when you migrate a VM or move a node; a persisted UUID survives migration and only changes on a genuine fresh install. It is also decoupled from rotatable crypto (the internal CA, the master key), so certificate renewal or key rotation never invalidates a valid license.

• It survives a restore. The ID and the stored license both live in the database, so restoring a backup onto a rebuilt host carries them along and Pro comes back with it. A fresh install is a new installation — it generates a new ID, and a license issued for the old one will not activate on it (see Installing & activating).

• It is not secret. The Ed25519 signature — not secrecy — is the integrity boundary, so the ID is shown openly in the UI and CLI.

• It is cluster-level. There is exactly one installation ID per Taranac deployment. Under HA the whole cluster shares a single logical database, so the ID is one shared value that replicates to every node — one ID, one .lic, per cluster (see HA / cluster licensing below).

Request a .lic through the Taranac portal — the signing itself stays offline and person-reviewed (there is no automated signer, and the private key never leaves TaranacLabs):

1. On your install, copy the installation ID (Licensing page or ./taranac installation-id).
2. Sign in at taranac.pro/app/license (Licensing & support in the portal menu) — enter your company and installation ID and pick a plan. Both plans grant the same thing, HA up to 8 nodes on one installation; they differ only in the length of the support window (1 month or 1 year).
3. We email an order summary and a payment request — nothing is charged at request time. Once payment is confirmed, TaranacLabs builds the payload — bound_to set to your installation ID, features: ["ha"], max_nodes, and the support window computed at signing time — signs it offline, and the signed .lic appears in the portal for you to download.
4. Upload it (next section). No network call ever leaves your install.

The portal allows one active license per account (an issued license or a request in flight). To renew, resize or replace one, email support@taranac.pro rather than filing a second request. Support can also be bought on its own, without a cluster and without an installation ID — that buys the support window only and issues no .lic.

Upload the .lic on Settings → System → Licensing (the upload card is gated by the license.manage RBAC permission; viewing the page and the installation ID needs license.view). Pick the file and it is validated and activated immediately — there is no separate “apply” step. Taranac stores it encrypted at rest in the database, as the single source of truth. There is no file-path or environment-variable alternative and no CLI upload, so there is never ambiguity about which license is active. A successful upload is recorded in the audit log with the license ID, organisation, granted features and max_nodes.

An upload is rejected (nothing invalid is stored) when the file is:

• malformed — not valid JSON (not_json), not the expected envelope (malformed), a payload that fails the schema (bad_payload), or an unexpected algorithm (bad_alg);
• signed by an untrusted key — an unknown key_id (unknown_key);
• tampered — the signature does not match the payload (bad_signature);
• bound to a different installation — its bound_to does not equal this install’s installation ID (bound_mismatch).

Those codes are what the UI localizes into the message on the upload card, and they are worth quoting when you contact support. The last case is the common one: a license issued for another installation ID will not activate here. Re-check that you sent the correct ID, and that you are uploading the file to the install it was issued for.

Uploading a valid file replaces whatever was stored before — that is the renewal and resize path. There is no “remove license” action: to go back to Community, replace the file or reinstall.

After a valid upload, confirm Pro is live:

• Edition badge. The Licensing page shows a Pro badge (versus Community) once a valid, correctly-bound license is active.
• Entitlements. The page lists the licensed details — organisation, granted features (e.g. an HA badge), max_nodes, issue date and license ID.
• Support status. Shown as active until <date>, permanent (no expiry), or an amber support expired warning — the warning never means a feature stopped.
• Dashboard widget. A License status widget on the dashboard mirrors the edition badge, the max_nodes cap and the support state at a glance (it needs license.view).
• License-invalid alert. If a stored license cannot be honoured (bad signature or wrong installation), Taranac raises a firing alert — fingerprint license:validation, source license, severity error — and runs as Community until it is fixed. The check runs on every boot and again after each upload, so a valid upload clears the alert immediately. See Alerts for how alerts fire, dedup and resolve.

Support expiry is a warning only — it never disables anything. When support.expires_at passes, every Pro feature keeps running (the functionality grant is permanent) and the UI shows a “support expired” banner. Because expiry changes nothing functional, clock drift is low-risk: the worst outcome of a skewed clock on an air-gapped box is a warning shown a little early or late, never a feature turning off. To renew support (or raise max_nodes), get a new .lic issued (email support@taranac.pro — the portal holds one active license per account) and upload it over the old one — entitlements are always “what the current file grants,” never additive across files.

High availability is a Pro feature, licensed at the cluster level — one .lic for the whole cluster, not one per node:

• An HA cluster runs on one shared logical database, so the installation ID and the stored license are single shared rows. The cluster needs one license, bound_to the cluster’s installation ID, granting features: ["ha"] and a max_nodes cap.
• Upload the license before you add nodes. Adding a node is refused unless a valid, HA-entitled license is present and the cluster stays within max_nodes. The order is: upload the cluster license on the existing node while it is still single-node, then join further nodes.
• Nodes inherit the license. A joining node bootstraps as a streaming replica and receives the installation ID and .lic from the replicated database — there is no per-node upload.
• Renewing or growing the cluster means issuing a new .lic (same cluster installation ID, updated max_nodes / support / features) and uploading it once — it replicates to every node.

Enforcement lives in one place — the cluster membership control plane — and is checked at three moments: when a join token is issued (./taranac cluster add-node does this for you), when a joining node redeems that token, and when it fetches the cluster configuration. All three refuse without features: ["ha"]; the first two also refuse when the cluster is already at max_nodes. Nothing else in the product asks about licensing.

A node counts against max_nodes when it is an active roster row — plus, importantly, every outstanding join token that has not yet been redeemed or expired, so several tokens cannot over-subscribe one free slot. Practical consequences:

• A witness does not count. It runs etcd only, has no roster row and is never issued a join token, so a two-node cluster with a witness needs max_nodes: 2, not 3. Standalone collectors and captive-portal hosts do not count either.
• A decommissioned node stops counting the moment it is removed, freeing its slot.
• An abandoned join holds a slot. A token issued but never redeemed keeps its slot until it expires (one hour by default), which is why cluster status can read 1 node / max 2 while an add is refused as at the licensed limit. Re-running add-node for the same address clears its own stale token; otherwise ./taranac cluster revoke --id <token-id> frees it.

What happens at the limit. Growth is refused with an explicit error — “This cluster is already at its licensed node limit (N). Upload a license with a higher max_nodes to grow further.”, or “A valid HA (Pro) license is required to add cluster nodes.” when there is no ha entitlement — and nothing that is already running is touched. A cluster that has somehow ended up over its cap, or running multi-node with no HA entitlement at all, is never stopped or degraded: it raises the cluster:max_nodes alert (re-evaluated hourly on the leader, and again on every membership change) and keeps serving. ./taranac cluster status opens with the same figures — N node(s) / max M — Pro (HA) or Community.

For the full HA setup, day-2 operations and the node-count model, see High availability; for the alert mechanics, Alerts.

• No phone-home. Licensing never touches the network: no online activation, no revocation callback, no license heartbeat. Verification is a local signature check.
• No hardware fingerprinting. Binding is a persisted installation ID, stable across VM migration.
• No usage metering or caps. Devices, users, groups, rules and policies are unlimited in both editions. Only features are gated.
• No license-driven failure of the core. A missing, expired, tampered or wrong-install license degrades only the affected Pro feature (HA collapses to single-node); AAA and NAC keep serving.
• No grace-period machinery. None is needed: nothing expires functionally, so there is nothing to grant grace on.

Licensing is honest about its own limits: an offline scheme can be worked around by cloning a whole deployment — DB, volumes and license together, carrying the same installation ID — and Taranac does not pretend otherwise. Binding stops the realistic case (one .lic dropped onto a second, unrelated install), not a determined copy. There is no private “Pro build” holding the line behind it either: one set of container images and one install bundle serve every install, and everything HA needs ships in them. What the license is layered on is the Elastic License 2.0 that Taranac ships under — free to use, including commercially and in production, but you may not provide Taranac to others as a hosted service, and you may not move, change, disable or otherwise circumvent its license-key functionality. The in-product check is designed to make issuance and renewal painless for the honest operator, never to hold the core hostage.

• High availability — the Pro feature this gates, and the cluster node model
• Alerts — where an unusable stored license surfaces
• Settings reference — the System → Licensing page in context
• RBAC — the license permission section (view / manage)
• Taranac on GitHub