Enterprise on-premise
All of Buff — inside your perimeter
The full product on your machines or in your cloud, independent of buff.systems: the same autonomous development, “Ask”, research and knowledge base — on your model, behind your single sign-on, with the audit log on your side. Below, point by point, for the security team, the CTO and the administrator of a closed network: what stays inside, who checks it and how it is maintained.
Objection 01
“Code and documents must not leave our perimeter — neither to you nor to a model provider.”
The first condition of any closed network. In the cloud a plan covers it; here the installation itself does.
Everything is with you: machines, data, model
Enterprise on-premise is installed by the installation wizard on your machines or in your cloud and runs independently of buff.systems. The contents of repositories, tasks and documents never leave the installation; models go through the installation’s gateway with your provider or local models.
Your model, your key
The installation wizard takes an OpenAI-compatible address — your LiteLLM, vLLM, Ollama — and a key; OpenRouter is not needed. The “class of work → model” logic is the same as in the cloud, but with your providers and local models.
What goes to buff.systems
Only the daily licence check — four fields: the installation ID, the version, the number of users and the number of runners; on our side the address the check came from is recorded. No content is requested or sent.
The code is the same
The editions differ in features, where they are installed and their terms — not in code. Autonomous development, “Ask”, research, the knowledge base, Buff Code and the phone app work with your installation.
What Community does not have
Several organisations in one installation, member roles and rights, email codes as a second factor, sign-up by invitation or through single sign-on.
Objection 02
“Our network has no internet. How do we even install this — and update it later?”
A closed network usually means “carry it over by hand, on your own”. Here the transfer is part of the kit.
An air-gapped network is a standard mode, not an exception
A release arrives on media, the licence as a file, and updates travel the same way. The buff-enterprise-kit.sh kit does it in three steps:
fetch — on a machine with access
Using the certificate, the script downloads the role images, release trees and stock images — PostgreSQL, Gitea, Windmill, Authentik, the model gateway and the rest — into one directory.
load — inside the network
The same script distributes the stock images to the installation’s machines over ssh.
serve — a local registry
Starts a registry with the release artefacts; the installation wizard is given its address. The certificate is entered as a file in the admin panel.
Objection 03
“Sign-in only through our directory. Someone who has left must not be able to open a single session.”
Separate passwords in yet another system are the first thing security forbids.
Single sign-on through your IdP: directory groups decide who goes where and with which role
The installation runs its own sign-in broker — Authentik — and registers the “Workspace” application in it. The broker connects to your provider through standard sources: Active Directory/LDAP, Keycloak, any SAML or OIDC. The sign-in screen has a “Sign in with single sign-on” button, and your provider confirms the sign-in.
Directory groups are roles
The group “buff: org <organisation>” means membership of the organisation, “… maintainer” the maintainer role. Groups are read at every sign-in: add a person and they are in the organisation, change their group and their role changes; without any such group, sign-in is refused.
One account per person
An email matching an existing account means the same account, with no password confirmation: the broker is yours. Password sign-in remains as a fallback, including for the administrator.
Screens in the Buff design system
Sign-in, application choice, the second factor and errors are styled with Authentik’s standard branding mechanism, without a fork — updating the broker does not break them.
Operators kept apart
Support operators, if you have them, sign in through separate groups and applications — users and operators do not mix.
Objection 04
“Security must see who did what and when — and not on the system’s word.”
A log that can be edited is not a log. This one is chained with hashes and verified by your own script.
The audit log — with you, in full, with an integrity check
Who signed in and from where, who changed rights, submitted a task or approved a publication, what the pipeline did — and every refusal: a wrong password, an action without the right. Entries are not edited or deleted and are kept for the whole life of the organisation — no 90-day window.
A hash chain
Each entry’s hash is computed from the previous one and its content (SHA-256): an entry cannot be inserted, changed or removed after the fact without it showing. Verification — with a button in the app or your own script on an export.
CSV and JSON Lines — for your SIEM
Everything matching the filter is exported, with no volume limit; the export is itself a log event. Secrets do not go into the log.
A separate right for the security officer
The log can be read and exported by the organisation owner or a member with a separate right — it is not part of any default role, not even Maintainer.
Each organisation has its own
Every organisation in the installation has this section separately. Pipeline actions are recorded as system events, refusals with the reason in the wording the person saw.
Objection 05
“Employees’ phones inside the corporate network are a separate risk.”
So the decision is the installation administrator’s, not the employee’s — and the administrator sees every connected phone.
Mobile access under the administrator’s policy
The installation’s admin panel has a “Mobile app” section. A phone acts on behalf of the employee and can do no more than they can in the workspace; the policy decides whether it can be connected at all.
The main switch
With “Mobile access enabled” turned off, the app does not connect to the installation and connected phones are disconnected. Changes take effect within half a minute.
Who can connect
“All employees”, “Roles only” — the selected roles — or “Not allowed for employees”. The installation owner can always connect their own phone.
Push — through buff.systems or off
Off — no notifications go to phones at all; what is waiting for an employee is visible in the app.
Phones, Buff Code machines and the log
All connected phones with a “Disconnect” button, the employees’ Buff Code machines covered by the same policy, and the log: who changed what and when. A disconnected phone wipes the installation’s data from itself.
The gateway does not see the content
The phone and the installation meet at the buff.systems gateway and encrypt everything end to end. The installation does not need inbound ports — only outbound access to buff.systems.
Objection 06
“Who supports and updates it — and do you need access inside?”
The question of the administrator who has to live with the installation. The answer: the wizard, the fleet and the contract; operator access is your choice.
The installation wizard, a worker fleet and support under contract
The wizard spreads the roles across machines and updates the installation from release artefacts. The worker fleet runs on several machines; machine requirements and the role layout depend on the load, and we agree them before installation.
Operator access — your choice
Access for our support operator — VPN and single sign-on for operators — is optional, under contract. Without it, support works from a diagnostic archive exported from the admin panel.
Usage accounting without money
Usage is counted by organisation and person — without wallets, plans or payment: the model and its key are yours.
Documentation — on this site
The same sections as for the cloud: development, “Ask”, research, the connector, Buff Code, the phone app.
Artefacts — by certificate only
Enterprise is not published in any form: the images, the wizard distribution, updates and the air-gap package are available only with a valid certificate.
Objection 07
“What happens to the installation if the certificate expires or the connection to you is lost?”
An honest answer matters more here than the word “perpetual”.
A time-limited certificate — and plainly what it stops
The licence is issued as a certificate with a limited term — monthly, or several months at once. Connected installations renew it automatically after renewal in our admin panel; in an air-gapped network the certificate is carried over as a file.
Expired or revoked
Only new tasks, runs, research and questions stop. Sign-in and reading remain — your data is not locked.
Price and request
250,000 ₽ a month, a licence per organisation; tokens are not counted — the model and its key are yours. A request opens a conversation: we reply by email, discuss the terms, and only then sign a contract.
Two editions on your side
Community or Enterprise
The code is the same. If three people and one organisation are enough, take Community. If you need several organisations, rights, single sign-on, audit, more people and runners, support or an air-gapped network — Enterprise.
What Enterprise adds
Row by row — from the editions table in the documentation.
| Community Edition | Enterprise on-premise | |
|---|---|---|
| Where it runs | on your machine | on your infrastructure: roles spread across machines |
| Organisations | 1 | several |
| Users and concurrent developments | 3 users, up to 15 developments | no limits — the only limit is the licence per organisation |
| Models | one OpenAI-compatible endpoint per installation | the installation’s LiteLLM gateway with your providers and local models |
| Member roles and rights | none — everyone sees everything | yes |
| Single sign-on (SSO) | none | yes, through Authentik to your IdP |
| Audit log | none | yes |
| Usage accounting | none | by organisation and person, without money |
| Sign-up | the administrator creates users | by invitation or through single sign-on |
| Email codes (second factor) | none | yes |
| Air-gapped network | by hand: images and a licence file | a transfer kit: releases on media, the licence as a file |
| Support | not provided — questions go to the repository | under contract; operator access optional |
| Licence | perpetual, with conditions | a time-limited certificate, monthly |
| Price | free | 250,000 ₽ a month, a licence per organisation |
| How to get it | from GitHub, with one command | under contract — request below |
Questions about self-hosting
What people ask next
How is Enterprise different from Community?
The code is the same; the features and terms differ: several organisations instead of one, roles and rights, single sign-on through your IdP, an audit log, usage accounting, a second factor, a worker fleet across several machines, an air-gap kit and support under contract. Community is one organisation, three users, up to 15 concurrent developments, one model per installation, no support.
Do we need access to OpenRouter or other external models?
No. Models go through the installation’s LiteLLM gateway with your provider: the wizard takes an OpenAI-compatible address — your LiteLLM, vLLM, Ollama — and a key; the home model is openai/<model name at the provider>. The “class of work → model” logic is the same as in the cloud.
What does the installation send to buff.systems?
With the daily licence check — exactly four fields: the installation ID, the version, the number of users and the number of runners; on our side the address the check came from is recorded. The contents of repositories, tasks and documents never leave your installation. In an air-gapped network the certificate is carried over as a file.
Do you need access inside our network?
No, unless you want it. Access for our support operator — VPN plus operator single sign-on — is an option in the contract. Without it, support works from a diagnostic archive exported from the admin panel.
Do the mobile app and Buff Code work with the installation?
Yes. A phone connects from the installation’s workspace; the phone and the installation meet at the buff.systems gateway and encrypt everything end to end — the gateway cannot see the content, and the installation needs only outbound access. The administrator decides who can connect phones and whether push notifications are sent; employees’ Buff Code machines signed in to the installation follow the same policy.
How do we get Enterprise?
Send a request on this page or write to the email in the “Contacts” section. After the contract you receive a certificate, access to the artefacts and instructions for installing with the wizard. Machine requirements and the role layout depend on the load — we agree them before installation.
Enterprise on-premise
Let’s discuss your installation
A request opens a conversation: we reply by email, discuss the load, the layout of roles across machines and the terms — and only then sign a contract. After it — a certificate, access to the artefacts and instructions for installing with the wizard.
Your security team’s questionnaire is welcome at info@buff.systems — we will answer point by point, with links to the documentation