GitRiver Licensing

This document covers the editions, what a seat gives you, how to buy, activate, and renew a licence, and what to do if paid features have closed. Legal terms are in the licence agreement: LICENSE.ru.md (original) and LICENSE.en.md (translation). In the interface, the same text opens at /legal — it ships with the product and is available without internet access.

Editions

There are three editions: Community, Pro, and Max. The Max edition includes Pro in full.

	Community	Pro	Max
Price	Free	Subscription, one month to one year	Subscription, one month to one year
Users and repositories	Unlimited	Unlimited	Unlimited
Seats	—	As many as the licence’s seat count (0 — unlimited); what a seat gives you — below	Same
Git, CI/CD, registry, Pages, wiki	+	+	+
Issues, pull requests, branch protection, CODEOWNERS, merge queue	+	+	+
Repository knowledge: index, drafts, outbound batch	+	+	+
Knowledge: my show and open counters	+	+	+
Knowledge: team roll-up, dead-memory analysis	—	+	+
Code index: symbol search, who calls whom	—	+	+
Vulnerability scanning, licence compliance, SBOM	—	+	+
DORA metrics and delivery flow	—	+	+
Custom roles, build variables, and group-level IP restrictions	—	+	+
LLM assistant: job and pull request review, settings and usage accounting	—	+	+
SAML SSO, SCIM, LDAP	—	—	+
Audit log	—	—	+
Quotas, installation-level IP restrictions, knowledge draft limits	—	—	+
Custom branding	—	—	+
Priority support	—	+	+

Features that are configured once for the whole installation and apply to all of its users — corporate sign-in (SAML, SCIM, LDAP), the audit log, quotas and draft limits, installation-level IP restrictions, branding — are part of the Max edition only. A Pro licence doesn’t unlock them, whatever its seat count (clause 4.2 of the agreement). The other paid features are unlocked by a seat in both Pro and Max.

The table matches the installation’s behaviour: anything not marked as paid in it works in Community too. Without an activated licence, the server runs in the Community edition.

An Edition This Version Doesn’t Know

If a licence is issued for an edition the installed version of GitRiver doesn’t recognize, the licence is accepted and the installation runs at Community level until it’s upgraded. The Administration / Licence page and the denial on a paid call both say so plainly: upgrade GitRiver; nothing needs to be repurchased (clause 4.11 of the agreement).

Editions Don’t Mix

Seats add up only within their own edition: Max with Max, Pro with Pro. A purchase is extended with a second licence of the same edition. A licence of a different edition, while another one is in force, is not activated — the denial names the cause. To move from one edition to another, contact the publisher: they will reissue the licence (see “What Changes on an Active Licence”).

An unlimited licence (seats = 0) counts no seats in either Pro or Max: nobody needs the seat flag, including those who can sign in only through corporate sign-in — as long as the Max edition is in force.

Non-production Installations

Besides the installation the licence was purchased for, the same licence covers up to three installations that do not serve end users: a test one, a pre-production one and a standby one, including verifying a restore from backup. They need no separate licence and do not count towards the number of seats (clause 2.6 of the agreement).

An installation that serves end users is not a non-production one, whatever it is called.

What a Seat Gives You

A seat is access. A feature marked in the table below as seat-metered is open to whoever has been assigned a seat, and closed to everyone else (clause 4.4 of the agreement).

A Max seat and a Pro seat are the same seat. Both editions unlock seat-level features alike; Max adds installation-level features on top. A seat is assigned by an administrator under Administration / Users — it isn’t handed out on first sign-in. Assigned and paid-for seats are shown under Administration / Licence.

Every feature has two independent properties: which edition it needs, and whether it’s seat-metered.

Edition	Seat-metered	What’s included
Max	no	SAML sign-in and provider metadata, corporate sign-in settings (SAML, SCIM, LDAP), account provisioning via SCIM, the audit log, installation-level IP restrictions, quotas, branding, knowledge draft limits
Pro	no	Assistant settings, usage accounting and spending limits, connectivity check with the model provider
Pro	yes	DORA metrics and delivery flow, security scanning, licence compliance and SBOM, code index, team knowledge roll-up, group roles and variables, group-level IP restrictions, assistant status and model requests

Administering the installation isn’t seat-metered: an administrator who has handed out every seat to staff still manages the settings and can upload a licence renewal.

“Not seat-metered” in the Max row means the feature is one per installation, not that people use it for free: anyone who can sign in only via SAML or a directory is asked for a seat right after signing in (see “Signing In by Means of Max Needs a Seat”).

An account without a seat that has a password or an OAuth link works at the Community level (clause 4.4 of the agreement): git, CI/CD, registry, issues, pull requests, repository knowledge, and personal counters are all available to it; paid sections answer 403 with code license_required.

A licence with no seat limit doesn’t count seats. At seats = 0 (clause 4.3 — the seat count is unlimited), the seat flag isn’t required: seat-level features are available to every account, including during the grace period.

On upgrading to 1.1.0, an installation with a licence limited BY SEAT COUNT will find that paid sections are available only to those already flagged with a seat — typically, just the administrator who activated the licence. Assign seats under Administration / Users. Installations with an unlimited-seat licence aren’t affected.

Knowledge is split by the same rule, and free and paid map to different addresses: /api/v1/repos/{owner}/{name}/knowledge/stats/me (free) versus .../knowledge/stats/team, .../knowledge/stats/dead, and /api/v1/admin/knowledge/limits/... (paid). The denial comes on the specific call, not as a field value inside a response.

Environment protection (/api/v1/repos/{owner}/{name}/environments/**, including deployment approvals) is a feature of the repository itself: it’s set up by the repository owner, and it works in Community too.

GET /api/v1/auth/me returns three flags:

• is_pro — “seat-level features are available to me” (a Pro or Max licence, and my own seat). The interface uses it to decide whether to show working sections;
• instance_is_max — “installation-level features are open” (the Max edition). It decides whether to show administration sections;
• instance_is_pro — “the installation has an active seat-level paid licence”. It tells “there’s no licence at all” apart from “there’s a licence, but I have no seat”.

When Access Is Denied

The denial names the cause, because causes are fixed differently:

Cause	What the person sees	What to do
No licence of the required edition	“This feature is available in the Max edition”	buy the edition
A licence of the required edition existed, but its term and grace period have both ended	“The Max edition licence has expired — renew it”	renew
The entitlement check hasn’t been renewed	“The right to paid features hasn’t been renewed since …”	check the connection to the licence server or enter the response manually (see “Entitlement Check”)
This version doesn’t recognize the licence’s edition	“This licence was issued for the ‘…’ edition, which this version doesn’t know”	upgrade GitRiver
The section is seat-metered, but the reader has no seat	“This feature is available to accounts with a seat — an administrator of the installation assigns it”	ask for a seat
The account signs in only through corporate sign-in and has no seat	“Signing in via SAML or a directory is part of the Max edition and requires a seat…”	ask for a seat
The account signs in only through corporate sign-in, and the Max edition isn’t in force	“Signing in via SAML and a directory is unavailable. … You can sign in with a password…”	ask the administrator for a password

The machine code is the same for all of them — license_required: the text is translated and refined, while the client picks its branch by the code.

Signing In by Means of Max Needs a Seat

Corporate sign-in — SAML SSO, an LDAP directory, and account provisioning via SCIM — is part of the Max edition. An account that can sign in only through those means gets no access without a seat: the sign-in completes, and then the person sees a message saying that a seat is assigned by an administrator of the installation.

The rule is simple: no password or OAuth — you need a seat. A password and OAuth need no seat and grant the Community level.

What counts is the account, not an individual sign-in: if the account has a password, it needs no seat even when the person signed in via SAML. The rule is the same for the web interface, git, SSH, and personal tokens.

An administrator who signs in with a password manages the installation without a seat. An administrator who signs in only through corporate sign-in needs a seat like everyone else. At least one administrator who signs in with a password always remains in the installation (see “Grace Period After Expiry”).

Signing in via SAML and via an LDAP directory works while the Max licence is in force or its grace period is running, and stops letting anyone in once the grace period has ended. Signing in with a password and through OAuth providers works at all times.

What Remains After the Licence Ends

Branding stays in effect as long as the Max licence does. Once the Max edition is no longer in force and its grace period has ended, the server shows the standard branding — both in the interface and on the sign-in page. The configured values are kept and reapplied once the licence is renewed: there’s no need to re-enter them.

What a paid feature set up stays visible and removable. Some paid features keep working after the licence ends: IP restrictions keep filtering requests, group variables keep getting injected into builds, custom roles keep granting permissions, quota defaults and knowledge draft limits keep constraining users. They can be viewed and deleted in Community too (GET and DELETE), while creating and changing them (POST, PUT, PATCH) needs an active licence; otherwise the answer is 403 license_required. In the interface, such sections are shown with their list and an explanation in place of the creation button.

Subscription and Term

GitRiver is sold as a subscription, from one month to a year. A licence carries two dates, and they must not be confused:

Date	What it means	What extends it
expires	how far it’s paid for	payment
lease_until	how far the installation is entitled to use what’s paid for without receiving a new signed response from the publisher	any new signed response: one the installation fetched on its own, or one entered by hand

The second one is called the entitlement-check period (the “confirmation period” in the licence agreement and on the licence page), and is described below, under “Entitlement Check”. Everything said in this section about terms, the grace period, and warnings refers to the first one.

A connection to the licence server is only needed so that renewals and the next entitlement check arrive on their own. Without it, the same signed response is entered by hand on the Administration / Licence page. There’s no separate licence format for an air-gapped installation: it gets a one-year subscription and a long entitlement-check period.

Renewal

1. Pay for the renewal in the customer portal (the Renew button next to the licence). The key, licence identifier, and activation are kept — there’s no need to enter a new key.
2. The installation fetches the renewal from the licence server on its own and applies it without the administrator’s involvement — usually within a day, and within a few hours close to the end of the term, during the grace period, and when the entitlement-check period is running out.
3. You don’t have to wait: the Check now button on the licence page requests the state immediately.
4. If there’s no connection to the licence server, get a renewed activation response the same way the licence was activated (see “Who Can Obtain a Signed Response”) and enter it on the same page.

What Changes on an Active Licence

Moving to a higher edition and buying extra seats aren’t a second licence purchase — they replace the activation file for the same one. The publisher issues a file with the same licence identifier; the term doesn’t have to move. The file is entered where a renewal is, or arrives from the licence server on its own. The installation tells the administrator everything that changed: edition, seat count, term. No second line appears in the licence list, and seats aren’t doubled.

Whether an incoming file is accepted depends on its term:

Term in the incoming file	What’s accepted
later than the active one	everything the publisher signed, including fewer seats or a lower edition under a new agreement
the same	only if the file makes nothing worse and improves something — this is how a move from Pro to Max, extra seats, and a routine entitlement check arrive
earlier than the active one	nothing

Within a paid term, conditions only improve: a file with the same term but fewer seats or a lower edition isn’t accepted (clause 4.10 of the agreement). None of these cases requires reactivating the installation.

Grace Period After Expiry

After the paid term ends, the paid edition is retained for a grace period. Its length is stated in the licence itself and by default depends on the subscription term (clause 4.6 of the agreement):

Subscription term	Grace period
1–3 months	7 days
4–11 months	14 days
12 months or more	30 days

During the grace period, paid features keep working — including SAML SSO sign-in and SCIM provisioning. Entitlement checks keep arriving during this time too, but they don’t move the paid term: the grace period ends on its own date.

No new seats are issued during the grace period, and seats assigned beyond the paid number count as an overage — which lets the administrator see ahead of time how many seats will be removed if they don’t renew.

When the grace period ends (clause 4.7 of the agreement):

• paid features are switched off, and seats beyond the limit are removed automatically (the most recently assigned ones first);
• corporate sign-in closes: signing in via SAML or a directory is no longer possible. A password and OAuth remain, and an administrator can set a password for anyone who used to sign in through the domain (Administration / Users);
• the data goes nowhere: the installation runs under the Community edition.

That’s why the last administrator who signs in with a password can’t be removed from an installation — not by demotion, not by blocking, not by deletion, not by being switched off through SCIM: otherwise, once corporate sign-in closes, nobody would be left to upload a renewal. An administrator who signs in only through OAuth doesn’t take their place: that sign-in depends on an external provider. To demote the last administrator with a password, set a password for another administrator first.

While the grace period is running, the interface shows everyone who is signed in a banner with its end date. The banner can’t be dismissed, and its text depends on what the reader stands to lose: someone who signs in through the domain is told they will stop being able to sign in, a seat holder that paid features will be switched off, an administrator that corporate sign-in will close. If the entitlement check has already run out, a message about the overdue entitlement check is shown instead.

Warnings Before Expiry

The administrator gets warnings ahead of time. Thresholds are set as a share of the remaining paid term — 25%, 10%, and 3%: for a monthly subscription that’s roughly 8, 3, and 1 day out, for an annual one 92, 37, and 11 days out. Each threshold fires once; after a renewal, the count starts over.

The warning goes out through three channels at once: a banner on the licence page, an entry in the activity feed (license_expiring), and an email to the installation’s administrators — to every unblocked administrator’s address. The same email also reports the start of the grace period, if more seats are assigned than are paid for.

For emails, the installation needs SMTP configured ([smtp] in settings, or the admin panel). Without it, the warning still lands in the server log and the activity feed, and the log gets a line stating there was nothing to send the email with.

The “receive emails” setting in your profile has no effect on these emails: that setting is about subscribing to repository events, while a licence warning is an installation-wide message.

Entitlement Check

A signed activation response is valid for a limited time — until the lease_until date, the entitlement-check period (the “confirmation period”, clause 4.12 of the agreement). This isn’t the licence’s term: the term says how far it’s paid for, while the entitlement-check period says how far the installation is entitled to use what’s paid for without receiving a new signed response. It’s extended by any new signed response: the installation requests one from the licence server on its own, and without a connection the response is entered by hand.

Its length is stated in the licence and by default depends on the subscription term:

Subscription term	Entitlement-check period
1–2 months	14 days
3–5 months	30 days
6–11 months	60 days
12 months or more	90 days

For installations without internet access, the entitlement-check period is set longer by agreement of the parties, up to a year.

The administrator hears about the entitlement check twice — through the same three channels as for the licence term (a banner on the licence page, the activity feed, an email):

• ahead of time — on the same share-of-remainder ladder (25%, 10%, 3%), but no later than 7 days before the end; the license_lease_expiring event;
• after the fact — once the entitlement check has run out and paid features have closed; the license_lease_expired event.

Each message goes out once per entitlement-check period. The email about an entitlement check nearing its end doesn’t ask for money — payment has nothing to do with it. Usually it asks you to open outbound connectivity from the installation to the licence server, or to enter a signed response by hand. If the licence is bound to a different database, the email says so and gives this installation’s database fingerprint for contacting the publisher (see “Moving the Database and Restoring From a Copy”).

In the API’s fields the entitlement check is called lease (lease_until, lease_days_left, lease_expired); in the interface it’s the “confirmation”.

What Happens When the Entitlement Check Expires

Git, repositories, CI, issues, search, and all your data keep working — at Community-edition level. Creating anything new through paid features is closed; what paid features already set up keeps working (see “What Remains After the Licence Ends”).

The entitlement check doesn’t touch the licence’s term or its seats:

• expires stays the same — what’s been paid for doesn’t go anywhere;
• staff keep their seat flags — nothing is removed;
• as soon as any new signed response arrives, paid features reopen on their own, with no further payment and no reactivation.

The entitlement check has no grace period of its own: the entitlement-check period itself is the time buffer.

What to do:

1. Open outbound connectivity from the installation to the licence server — it will request the entitlement check itself; the Check now button doesn’t wait for the next check.
2. If there will be no connection (an air-gapped installation), obtain the response by hand (below).

Manually Renewing the Entitlement Check

The manual path is on equal footing with the automatic one, and for air-gapped installations it’s the primary one. The administrator gets a signed activation response from the customer portal (or, without an account, by licence key — see “Who Can Obtain a Signed Response”), carries it inside the perimeter, and enters it on the Administration / Licence page — the same route the licence was activated by. The result is the same as with an automatic check.

Moving the Database and Restoring From a Copy

A licence is bound to the installation’s database (clause 4.13 of the agreement). Restoring the database from a backup into a new cluster and a major PostgreSQL upgrade change that binding. The licence page then shows a “The license is bound to a different database” banner with THIS installation’s database fingerprint — the one you give when contacting the publisher.

What to do:

1. No need to rush: the previous entitlement check stays valid until the end of its period, and paid features keep working until then.
2. Request a reissue: on the licence page, click “Add license” and enter the same licence key — the installation prepares a new activation request — and obtain a response to it the same way the licence was activated. If the key isn’t at hand, give the publisher the fingerprint from the licence page and ask for a reissue. A reissue is free of charge.
3. Enter the response you receive by hand on the same page. An automatic entitlement check doesn’t rebind a licence to a different database.

It’s convenient to plan a database upgrade together with the reissue: request it in advance, not after the entitlement check is about to run out.

Keep the time on the installation’s servers and the database servers synchronized (NTP). If the clock ran far ahead, the licence term and the entitlement-check period may end earlier than the calendar says; the same reissue of the activation response fixes it.

Licence Activation

The first activation is a challenge-response procedure and doesn’t require the installation to have internet access (clause 4.8 of the agreement).

Flow

1. Get your licence key at purchase.
2. In the interface (Administration / Licence), paste the key and click “Prepare”.
3. Copy the generated activation request.
4. Open the customer portal on the licence server, the Licences section (https://gitriver.ru/cabinet/licenses), signed in as the licence owner’s account, click “Activate” next to the licence, and paste in the activation request — the portal issues an activation response, which you can copy or download as a file.
5. Paste the activation response into the GitRiver interface and click “Activate”.

The installation’s administrator may have no portal account at all — in that case, the response is obtained by licence key (below).

Who Can Obtain a Signed Response

A signed activation response is only issued to whoever has proven a right to the licence. There are two paths:

Path	What proves the right	What’s presented
Customer portal (primary)	signing in as the licence owner’s account	the activation request
By licence key	possessing the key	the licence key, the installation identifier, and its database fingerprint

Keep the licence key secret: whoever presents it gets an activation response.

If the key is lost and the owner’s portal account can’t be used, contact the publisher (see “Contacts”): a member of the publisher’s staff issues the response on the owner’s behalf.

Activation by Licence Key

The path for those with no account on the site. There’s no page for this path: the response is requested from the licence server with a call (the same address as the license_server_url setting):

curl -X POST https://gitriver.ru/api/licenses/activate \
  -H 'Content-Type: application/json' \
  -d '{"license_key": "<license key>",
       "instance_id": "<installation identifier>",
       "db_fingerprint": "<this installation's database fingerprint>"}'

The installation identifier and database fingerprint are shown on the Administration / Licence page — the “Instance” and “Database fingerprint of this instance” rows; the identifier appears once “Prepare” has been clicked (step 2).

The response arrives in the activation_key field — that’s the activation response, and it’s what you paste on the licence page (step 5).

Details

• Activation is stored in the installation’s database. A backup made with the standard backup command preserves it. Resetting the database (including on a test environment), or restoring from a backup taken BEFORE activation, means a new installation: the previous activation stays spent, and the licence has to be activated again.
• Operation doesn’t depend on connectivity — renewals and entitlement checks can be carried over by hand (see “Entitlement Check”).
• No deactivation — an activation is spent for good and can’t be transferred to another installation.
• A cap on activations — each key has a limited number of activations.
• No trial period — before activation, the installation always runs the Community edition.
• The installation identifier isn’t tied to hardware — this suits Kubernetes: a pod can be recreated without losing the identifier or the activation.

Multiple Replicas

Replicas are free and unlimited in number: the licence applies to the installation as a whole, not to an individual pod.

• Activation takes effect on every replica with no pod restart — usually within a fraction of a second; if a replica has lost its database connection at that moment, as soon as the connection is restored; in any case, within a minute.
• The same goes for removal — deleting a licence, revocation by the publisher, and term expiry all reach every replica the same way.
• No more seats are issued than are paid for, even when they’re assigned simultaneously from different replicas.

The Licence Page

The Administration / Licence section shows:

• the installation’s summary status, the highest edition in force, and the assigned and paid seats;
• the installation identifier and its database fingerprint — you give them when activating by key and when contacting the publisher;
• for each licence: the owner, edition, seat count, term, grace period length, and the date the entitlement check is valid until;
• banners for whatever needs action: the term or the entitlement-check period is nearing its end, the grace period is running, the entitlement check is overdue, the licence is bound to a different database, the licence’s edition is newer than the installation’s version;
• the date terms are currently counted from — if it differs from the server’s clock;
• the “Check now” and “Add license” buttons and licence deletion.

Status Through the API

GET /api/v1/admin/license

The response describes the installation as a whole, not a single licence: there can be several, and the top-level fields bring them together.

Field	What it means
status	Summary status of the installation, see below
plan	The highest edition among the active licences
is_pro	Whether a paid seat-level licence is active ON THE INSTALLATION (same as instance_is_pro in /auth/me)
is_max	Whether installation-level access is open — the Max edition (same as instance_is_max)
unknown_plans	Editions from licences this version doesn’t recognize; non-empty means the installation needs an upgrade
total_seats	How many seats are paid for; 0 — the seat count is unlimited (clause 4.3 of the agreement)
seat_limit	The same limit in a display-friendly form: null when there’s no limit
assigned_seats	How many seats are currently assigned
instance_id	The installation identifier that activations are bound to
licenses[]	One entry per licence: id (the record’s identifier — used to delete it, see DELETE /admin/license/{id}), license_id (the publisher’s identifier), owner, plan, is_pro, is_max, plan_supported, seats, expires, days_until_expiry, activated_at, status (active/grace/expired), grace_days, grace_days_remaining, expiry_warning_percent, lease_until, lease_days_left, lease_expired, db_moved
grace_period	Filled in when more seats are assigned than paid for AND the grace period is running: excess_seats, grace_end, days_remaining
pre_expiry_warning	Some active licence’s term is running out
lease_warning	Some active licence’s entitlement-check period is running out
lease_expired	Some licence’s entitlement check has run out: the term is paid for, paid features are closed
db_moved	Some licence is bound to a different database
db_fingerprint	This installation’s database fingerprint — you give it to the publisher when asking for a reissue
pending_activation_request	An activation that’s been started but not completed
effective_date	The date terms are currently counted from, if it differs from the server’s clock

The summary status (status) is one of five values:

• active — paid features are enabled;
• grace — the term has ended, but the grace period is running and paid features work;
• pending — activation has been started (prepare has run), but the activation response hasn’t been entered yet;
• expired — the term has ended, and the grace period is over;
• community — there’s no licence at all.

API

Method	Path	Description
GET	/api/v1/admin/license	Licence status
POST	/api/v1/admin/license/prepare	Enter a licence key, get an activation request
POST	/api/v1/admin/license/activate	Enter an activation response: activating a paid edition, a renewal, or an entitlement check
POST	/api/v1/admin/license/heartbeat	Request the licences’ state from the licence server right away
DELETE	/api/v1/admin/license/{id}	Delete a single licence
DELETE	/api/v1/admin/license	Delete all licences (revert to Community)

An administrator deleting a licence, and the removal of a licence revoked by the publisher, are recorded in the audit log as the license_deactivate event with a cause: admin, admin_all, or revoked_by_issuer. The entry for a removal by revocation is signed “System”. Revoking one licence doesn’t affect the installation’s other licences.

Information the Installation Sends to the Publisher

An installation with an activated licence periodically contacts the licence server (an outbound HTTPS connection to the address in the license_server_url setting) and sends the following (clause 7.1 of the agreement); the list is complete:

• the installation identifier (instance_id); it isn’t tied to hardware;
• the GitRiver version;
• the list of its licences with their terms and seat counts;
• the number of accounts — every registered one, including blocked ones and ones disabled by provisioning;
• the number of repositories — all of them, including forks, mirrors, and archived ones;
• the number of assigned and paid seats;
• two anonymised fingerprints — of the database and of the installation’s address. Neither the address nor the database content can be recovered from them.

The installation does not send (clause 7.2 of the agreement): repository content, files, source code, commit messages, issues, builds, users’ names and email addresses, credentials, the server’s address and name, or machine details (CPU, memory, disks, operating system, network addresses).

An installation under the Community edition, and an installation with no connection to the licence server, send nothing (clause 7.4 of the agreement). There’s no separate switch for this exchange: it stops once no licences are left in the installation. An unreachable licence server switches nothing off — the installation just won’t receive renewals and entitlement checks on its own, and they can be entered by hand.

Contacts

• Purchases, renewals, moving to another edition, reissuing an activation response, a lost key, and other licensing questions — info@gitriver.ru.
• The customer portal with your licences — https://gitriver.ru/cabinet/licenses.
• Vulnerability reports — security@gitriver.ru.