Enterprise Server
Settings
Settings is for server admins: one page per section, listed beside it in four groups — Server, Sources, AI and Governance. Credentials only go in; once saved they are sealed on the server and never shown again.
Readiness
Where Settings opens: the checks the server itself derives — the database connection, its migrations and row-level security, storage, the licence from Knwlge Global, the key service that seals provider keys, and Redis when one is configured — each passing or saying what is wrong. The same checks answer /readyz and go to Knwlge Global in the status report. This page never decides permissions; it only reports.
Enterprise Server
What setup decided, as the server sees it now: the server's URL, the Knwlge Global it is enrolled with, its version, its storage and the sign-in methods it accepts. The URL, the Global link and storage are bound to the enrollment and the machine, so they change with knwlge-enterprise setup and a restart.
The AI clients people may use can be changed here — Codex, Claude Code, GitHub Copilot, Cursor, Grok — and the change applies at once. It wins over the setup file until Use the setup file's list resets it.
Sign-in
Everyone signs in at Knwlge — with a password, with Microsoft (work or school accounts) or with GitHub — and each token says which. This section decides what this server accepts:
| For each method | What it does |
|---|---|
| Accept sign-in with … | Off: nobody who signed in that way gets in, and the sign-in page has no button for it. At least one method stays on. |
| Allowed email domains | Empty: any address. Otherwise the address must end in one of the domains — say acme.example, up to 20. A subdomain is a domain of its own. The address checked is the one the provider verified, or the Knwlge account's own for a password. |
- It holds on every request — for the console and for every CLI, sessions that already exist included — within five seconds on every server. Someone turned away is told what they used and which methods are accepted, never the domains.
- You cannot lock yourself out. A change that would turn away the admin saving it is refused with the reason. If the settings ever turn everyone away,
knwlge-enterprise config reset-sign-inon the server undoes them (Locked out of sign-in). - Project membership still applies: these settings narrow who gets in, never widen it. Every change is audited with the settings before and after.
Updates
The version this server runs, whether a newer release exists, and every release Knwlge Global offers, each with its notes. On a server installed with the install script, Update to … asks for confirmation and then follows the update step by step:
| Release | Published | What's new |
|---|---|---|
| 1.5.0 | Sep 29 | Prompts dashboard; Overview shows assistant usage; sign-in by email domain. |
| 1.4.2 | Sep 22 | Running now. |
| Outcome | What the page says |
|---|---|
| Updated | The versions, how many database changes were applied and how many rows the data guard watched over — and Reload the console, since the browser still holds the old version. |
| Not updated | The step that failed and why. Nothing changed; the server runs the version it had. |
| Went back | The new version did not start, so the server returned to the one it had. |
A Homebrew, container or source install, or one the server's account may not write to, is told what to run instead. The details, and how the data stays safe, are in Running the server.
Knwlge Global
The server's enrollment as it sees it: Enrolled, Enrollment required or Not enrolled; the server id, the project, the enrollment key's name, prefix and end date, the licence and its expiry, the last heartbeat and status report, and when Knwlge Global last accepted a call.
Enter a new enrollment key when Knwlge Global refuses the old one. The server checks the key with Global, refuses a key made for another project, re-enrolls with a fresh key pair and sends a heartbeat at once — keeping its database and every row. The key is never stored by the console, logged or audited; the re-enrollment is.
Branding
Upload the server's logo — shown instead of the Knwlge mark in the sidebar and on the sign-in page — and a sign-in background. PNG, JPEG, WebP or SVG; the logo up to 1 MB, the background up to 8 MB. Files are checked by their content, not their names: an SVG with scripts or event handlers is refused. They are kept in the server's own storage and served publicly — the sign-in page needs them before anyone signs in — and every change is audited without the file.
GitHub, Azure DevOps and connectors
- GitHub App — create a GitHub App for your organization (repository contents, metadata, pull requests and issues, read), give it the setup and webhook URLs the page shows, and paste its id, private key and webhook secret. The server proves the id and key against GitHub before saving.
- Azure DevOps — the organization URL and a personal access token or a Microsoft Entra service principal, plus an optional service-hook secret. The server lists the organization's projects with them before saving.
- Connectors — Azure DevOps wikis indexed as team knowledge. Other kinds stay hidden until each passes a live validation.
Saved here, credentials take effect at once and win over the same settings in the environment. The page only says whether each secret is set.
Embedding provider and provider keys
- Embedding provider — which provider turns repository text and questions into vectors, with its model, dimensions and endpoint. Source text and query text are sent to it. Changing the provider, model or dimensions creates a new vector space and a controlled re-index; the previous space is kept for a rollback window. A configuration that is incomplete or failed its last test stops indexing rather than degrading quietly.
- Provider keys — keys for the embedding provider and for optional LLM assistance (summaries, catalog descriptions, extraction). Encrypted on the server, never shown; rotating replaces the key, deleting disables provider calls until a new one is saved. LLM assistance is off until a limit is set (LLM assistance), and every call is redacted first.
Session capture
The organization's capture policy, which every connected sidecar reads and the server enforces again on upload:
| Mode | What is kept |
|---|---|
full | Prompts and what happened in each session, redacted on the developer's machine and again here. Admins can read the prompts on the Prompts page; every view is audited. |
metadata_only | File paths, tool names and exit statuses — no prompts or other text. Token counts still arrive. |
off | Nothing. |
A member who opts out on My memory is never captured, whatever the mode. Tell your members what you chose — the Prompts page and the opt-out are described for them in Session capture and learning.
Configuration
Every KNWLGE_* setting the server declares, with its type, default and whether it is set. Flags, choices and numbers show their value; secrets and free-form text never do.
On a server started with knwlge-enterprise start, admins can change the behaviour settings here — memory policy, retention, sync daemons, LLM limits, the context kill switch. A change is saved at once and takes effect when the server restarts: the page counts the waiting changes, and Restart server asks the process to start again. If it cannot start with the new values, it starts with the last values that worked and says why, so a bad value never keeps the server down.
Secrets, host paths, settings fixed at setup and settings the server does not read cannot be changed here, and the page says why for each. A value set in the server's own environment always wins and locks the setting. Under Docker Compose or Helm the page is read-only. Which is which, setting by setting: Configuration reference.
