Configuration
Kisuno is configured in three places. Knowing which place is responsible for what, and which level wins in a conflict, saves you the search.
The three levels
Section titled “The three levels”| Level | Place | Content | When it takes effect |
|---|---|---|---|
| Infrastructure and secrets | Environment file of the instance | Addresses, keys, operating parameters | after a restart of the application |
| Product behaviour | librechat.yaml |
Model cards, interface, connectors, registration | after a restart of the chat service |
| Runtime overrides | Admin panel, page Configuration | the same product settings, per instance, role or group | immediately, without a restart |
The environment file is created during installation from a template that is commented throughout. It states for every value what it is needed for.
Which level wins
Section titled “Which level wins”A value set in the panel sits above the YAML. The panel writes its values into the database, the application reads them on the next call and they survive a restart. The YAML remains the initial state that applies as long as no override exists.
In the panel you recognise this by two details: sections with an active override carry the badge from DB override, and next to every overridden field there is an icon to remove it.
For model cards an additional cascade applies: group before role before base. Permissions for tools, by contrast, belong in the role editor and not in the configuration; in the features tab they would be discarded server-side.
The interface block
Section titled “The interface block”The interface block in the YAML controls what is visible in the interface: the model picker,
web search, file search, code execution, presets, bookmarks and the parameter panel. Features
whose prerequisites are not met are deliberately switched off on delivery. A visible button
without effect is worse than no button.
Two rules matter here:
- The block is global. The values are written into all roles on start. A difference between roles therefore cannot be expressed in the YAML. If a tool is to be released for one role only, leave the field out of the YAML and set it in the role editor of the admin panel.
- Capability lists replace rather than merge. Anyone who touches the list of agent capabilities replaces the default list completely. Nothing is merged, so everything to be kept has to be listed again.
For companies that want the plainest possible interface, the controls that only power users need can be switched off as a group.
Domain lock
Section titled “Domain lock”The domain lock is the first step after the installation and belongs in place before the instance is reachable under its domain. What matters is the list of allowed e-mail domains: it decides who can create an account at all.
The list is stored in the configuration of the instance; you maintain the same list in the panel under Configuration in the features tab in the field Allowed e-mail domains. It applies to self-registration and to invitations: an invitation to an address outside the list has no effect.
You can verify this with a registration under a foreign domain; it has to be rejected.