Athenode Pro tiers

Athenode Pro comes in three tiers: Pro Solo, Pro Team and Pro Enterprise. Athenode Pro is the Athenode server a team runs itself, with accounts, project roles and a licence. A tier belongs to an organisation in your Athenode account, and it sets how many accounts the organisation's Pro servers can enable, which features they turn on and the support the organisation gets. Every tier includes all three modules: specifications, plugins and the SSH gateway.

Tier	Seats	Two-factor sign-in	Health webhooks	Audit history, export and forwarding	Roles and access control	Single sign-on	Support
Pro Solo	1	No	No	No	No	No	Standard support
Pro Team	8	Yes	Yes	Yes	Yes	No	Standard support
Pro Enterprise	Unlimited	Yes	Yes	Yes	Yes	Yes	Priority support

A seat is one enabled account on the Pro server, the first administrator included. Pending invitations and disabled accounts take none. Billing for Athenode Pro describes subscribing to a tier and changing it, and the pricing section of the Athenode website shows the price of each tier.

What each feature covers

Each feature is listed in the organisation's licence key, and the Pro server turns it on while the key lists it. The License page of the server names each one as "included", or as "not included" with the tier that has it, as the Pro licence describes.

Feature	Name on the License page	What it turns on	Lowest tier
Two-factor sign-in	Two-factor authentication	A one-time code at sign-in for built-in accounts, which an administrator can make mandatory, as Users and sign-in describes	Pro Team
Health webhooks	Health webhooks	Signed webhook calls when a service of the SSH gateway goes down or recovers, as Services and health checks describes	Pro Team
Audit history, export and forwarding	Audit history, export and forwarding	The History page of each project, the audit export as CSV or JSON and the forwarding of each entry to a syslog server or a webhook, as Audit export and forwarding describes	Pro Team
Roles and access control	Roles and access control	Project roles for accounts and groups, the groups themselves, personal credentials and the credential mode of a connection, as Project roles describes	Pro Team
Single sign-on	Single sign-on (OIDC)	Sign-in through your identity provider, and groups linked to its groups claim, as Users and sign-in describes	Pro Enterprise

The whole audit history is a Pro Team and up feature: the History page, the export and the forwarding. On every tier, the server keeps recording the audit entries, so the history of a Pro Solo server becomes visible after an upgrade.

Every tier has accounts with invitations, built-in passwords, sessions, personal access tokens, search by meaning and the Athenode MCP server with OAuth sign-in.

Upgrade the tier

A billing administrator upgrades the organisation's tier in the Subscription panel, as Billing for Athenode Pro describes. The upgrade applies at once, and the difference for the rest of the current period is charged at once.

Your Pro server turns the new features on with its next licence key, without a restart:

1. On the server, an administrator opens License and selects Check now. The server fetches a new key with its stored licence token, and the page says "Checked: the license key was renewed."
2. If the server imports its key by hand, the page says "Check now needs a stored license token." A billing administrator downloads a new key, and an administrator imports it as the Pro licence describes.

Without either, the server receives the new key at its next daily renewal. Everything a downgrade stopped applies again with the new key: stored roles, groups, access rules, two-factor enrolments, webhooks and forwarding targets.

Downgrade the tier

A downgrade takes effect at the end of the current period. Until then, the organisation keeps its current tier. When the lower tier drops features, the Change plan dialog lists them under "When the change takes effect:" and asks you to tick "I understand that these features stop working on our Pro servers." before you confirm.

The Pro server applies the lower tier when it receives a key of that tier, at its first renewal after the end of the period, or at once with Check now.

What stops after a downgrade

The server stops applying each feature the new key lacks. It deletes nothing: settings, roles, groups, rules, enrolments and targets stay stored and apply again after an upgrade.

Single sign-on

Single sign-on stops when the tier is lower than Pro Enterprise. Accounts that sign in with single sign-on cannot sign in, and the sign-in page says "Single sign-on needs the Enterprise plan, which this server's license does not include. Ask an administrator."

An administrator moves each of these accounts to a password:

1. On the Users page, select Move to password on the account.
2. Confirm in the dialog. The account's sessions and tokens end, and the page shows a one-time link.
3. Hand the link to the person, who sets a password with it. The link is never emailed.

On the server machine, recover does the same:

athenode-pro recover --email <address> --move-to-password

The move is for good. The account keeps its password and its groups after a later upgrade, and single sign-on for its email address is then refused.

Two-factor sign-in

On Pro Solo, no account is asked for a code at sign-in, also an account that turned two-factor sign-in on, and the setting that makes it mandatory is not in force. The enrolments are kept, and the code is asked again after an upgrade. The Users page marks an enrolled account "2FA not active".

Roles and access control

On Pro Solo, roles, groups and access rules are stored but not applied. Every account acts as an owner of every project, and server administration stays with the server's administrators. Connections use only their shared credentials, personal credentials have no effect and a new connection always uses shared credentials. The Members page of a project says that project roles are not applied on this tier.

Health webhooks and the audit

On Pro Solo, health webhooks stop sending and audit forwarding stops. The History page of each project is locked and says "The audit history is part of Pro Team and above.", and the audit export is unavailable. Browser notifications for services keep working.

Seats over the new limit

When the new tier has fewer seats than the server has enabled accounts, every enabled account keeps working. No account can be invited, added or enabled until an administrator disables enough accounts, and the License page says "The license allows" the number of seats "but" the number of enabled accounts "are enabled."

The v3 licence key

A v3 key is the licence key format that carries the tier, the seats, the modules and the features. Athenode issues v3 keys only. A v3 key needs Athenode Pro 0.13.0 or later. An earlier version refuses it with "the key has an unsupported format version", as Troubleshooting describes.

Athenode Pro 0.13.0 and later accept v3 keys only. When you upgrade a server that holds an earlier key:

• With a stored licence token, the first start renews the key online and serves with the v3 key it gets.
• With an imported key and no token, the server refuses to start until you import a v3 key. A billing administrator downloads the key from the organisation's page, and you import it with athenode-pro license import --file athenode-pro-license.key before the start.

When a feature is not in your tier

A page or setting of a feature that the licence key lacks shows the feature as Locked, with "Available in Team and above" or "Available in Enterprise" and a link, Open the organisation console, to the organisations of your Athenode account.

An API request or an Athenode MCP tool call that needs the feature is refused with HTTP status 403 and a JSON body with error, code, feature and minimumTier. code is feature_not_licensed, feature is the feature's id and minimumTier is team or enterprise.

Feature id	Feature
two_factor	Two-factor sign-in
health_webhooks	Health webhooks
audit_export	Audit history, export and forwarding
access_control	Roles and access control
sso	Single sign-on