Enterprise Server
Running the server
Day-to-day operation of an Enterprise Server installed with the install script or Homebrew. For Kubernetes, the Helm chart's own guide in the Enterprise Server repository covers the same ground.
The knwlge-enterprise command
| Command | What it does |
|---|---|
setup | Interactive setup: link to a project, database, storage, clients, sign-in. Run again to change what setup decides. |
start | Run the server — migrations, the API and console, the worker and scheduled jobs — until Ctrl+C. |
status | Configuration, enrollment, readiness and updates; exits 1 when not ready or refused. |
service install | uninstall | A systemd unit (--user for a per-user one) or a launchd agent. |
enroll | Enter a new enrollment key when Knwlge Global refuses this server. Keeps all data. |
update [<version>] [--check] | Install the newest release, or that one, beside the running one and migrate. |
migrate [--plan] [--json] | Run the database migrations only, under the data guard; --plan changes nothing. |
config show | path | Print the configuration with secrets masked, or where it is. |
config reset-sign-in | Undo the sign-in settings saved in the console. |
profiles | The servers set up on this machine. |
version | The version. |
Files live under ~/.knwlge-enterprise (/etc/knwlge-enterprise when run as root): config.json — readable by its owner only — state.json and logs/.
Status
knwlge-enterprise status reads the configuration and asks the running server how it is: process, enrollment and key, database, storage, readiness and whether an update is available. It exits with 1 when the server is not ready or Knwlge Global is refusing it, so it doubles as a health check. The console's Readiness and /readyz show the same checks.
Run it as a service
knwlge-enterprise service install # systemd on Linux, launchd on macOS
knwlge-enterprise service install --user # Linux: a per-user unit under ~/.config/systemd/user
The service runs start and restarts it if it stops. Settings changed in the console that need a restart are applied with Restart server on the Configuration page; the service brings it back.
Updates
An update is always an admin's decision; the server never updates on its own. When Knwlge Global knows a newer release, start logs one line and status and the console show it.
- From the console — Settings → Updates, Update to …. The release for this machine is downloaded, its SHA-256 must be the one Knwlge Global lists (anything else is deleted), it is unpacked beside the running version, the new version migrates the database, and the server restarts into it in place. Until the restart it keeps serving on the old version; if the new one does not start, it goes back.
- From a terminal, with the server stopped or running elsewhere:
knwlge-enterprise update --check # what is installed, what is offered; changes nothing
knwlge-enterprise update # the newest release
knwlge-enterprise update 1.5.0 # that release
# then restart the server, or its service
A Homebrew install updates with brew upgrade replient/tap/knwlge-enterprise, a container with a new image tag. Who asked for an update and how it ended are in the audit log.
What keeps the data safe
- Migrations only add, by policy. A migration that drops or rewrites anything is refused unless it is declared as such.
- The data guard. Every migration — at start, from an update, from
migrate— runs in one transaction that compares the database before and after. A table or column that went away, a table emptied, or rows deleted without the migration declaring it roll the whole transaction back, and the command names the table and the count. - The rehearsal. Before a release is published, the pipeline builds a database at every released version's schema, fills every table, updates it to the new code and compares every row. A release that would cost an install its data is not published.
Enrollment keys
The server stays bound to the key it enrolled with. If that key is deactivated or passes its date, Knwlge Global refuses the server's heartbeats and reports, and developers are turned away until someone enters a new key — nothing else needs setting up again, and no data is lost:
knwlge-enterprise enroll # asks for the key
echo "$KEY" | knwlge-enterprise enroll --key -
Or in the console, under Settings → Knwlge Global. A key kept in config.json re-enrolls the server on its own while it is still active.
Locked out of sign-in
The console refuses a sign-in change that would turn away the admin making it. If the settings ever turn everyone away anyway — a mistyped domain, a provider that is down — undo them on the server:
knwlge-enterprise config reset-sign-in
The setup file's list of methods applies again, from any address, until an admin saves new settings.
Several servers on one machine
One machine can run several servers — for two projects, say. Each has its own directory under ~/.knwlge-enterprise/profiles/<name>/; the first is the default one.
knwlge-enterprise setup --profile northwind # creates it when it is new
knwlge-enterprise start --profile northwind
knwlge-enterprise profiles
Without --profile, commands ask which server you mean when there is more than one.
Backups
- The database holds the index, knowledge, memories, sessions and audit. Turn on point-in-time recovery where your Postgres offers it, and take a logical backup daily and before every update:
pg_dump --format=custom --no-owner. Restore into a scratch database to rehearse, never over the live one. - Storage holds session digests, uploads and branding. Use your provider's versioning or replication.
config.jsonholds the secrets setup generated, including the key that seals provider keys and integration credentials. Keep a copy somewhere safe: a database restored without it cannot open them.