Get started

Getting started

Enterprise installation

Stand up an Enterprise Server on your own machine or cloud and enroll it with Knwlge Global. Your code, knowledge and memory stay on your infrastructure; Global handles identity, licences, usage counts and a health view.

Who this is for

The engineer installing Knwlge for an organization on the Enterprise plan. One command installs the server, a setup wizard links it to your project, and the first context card is minutes away. Once the server is running, developers follow the CLI installation guide against its URL.

Before you begin

  • A machine to run it on — a Linux VM or a Mac — with a public HTTPS hostname in front of it (a reverse proxy, a load balancer, or an ngrok tunnel while you evaluate), for example knwlge.company-a.com. This is the server's canonical URL and the audience of every token it accepts.
  • PostgreSQL 18 with pgvector — managed or on the same machine (brew install postgresql@18 pgvector on a Mac). The wizard asks for one connection URL; migrations run as that role and the server itself runs as a limited tcg_app role the migrations create.
  • Somewhere to keep artifacts — a directory on the machine, a mounted Azure File Share, an S3-compatible bucket or an Azure Blob container. Nothing else: Redis is optional for a single server and a default install makes zero LLM calls.
  • An enrollment key for the project, from the Global App (My Projects → the project → Enrollment keys). Organization admins and project admins create them.

Install and enroll

  1. Install the command

    macOS with Homebrew:

    shell
    brew install replient/tap/knwlge-enterprise

    Linux or macOS without Homebrew (installs to /opt/knwlge-enterprise, or under your home when not root):

    shell
    curl -fsSL https://raw.githubusercontent.com/Replient/knwlge-releases/main/install.sh | sh
    shell
    knwlge-enterprise --version

  2. Run the setup wizard

    Open the project under My Projects and create an enrollment key under the Enterprise Server — it is shown once, so copy it then. A key is reusable until it is deactivated or passes its valid-until date (a year). Then:

    shell
    knwlge-enterprise setup

    The wizard walks through, in order:

    • Link to the project. Paste the enrollment key; the wizard shows the project, organization and server URL the key was made for, and asks you to confirm this machine answers at that URL.
    • Database. A PostgreSQL connection URL. It is tested on the spot, including that pgvector is available.
    • Storage. Local directory, Azure File Share (a mounted path), S3-compatible bucket or Azure Blob container — each verified with a write, read and delete.
    • Clients. Which AI clients people may use with this server: Codex, Claude Code, GitHub Copilot, Cursor, Grok. Anything unticked is refused. Local LLMs are coming soon.
    • Sign-in. Knwlge sign-in is always available; add Microsoft (Entra ID) — GitHub is coming soon. Sign-in itself happens at knwlge.com; the server only records what it allows.

    Answers land in ~/.knwlge-enterprise/config.json (owner-only permissions), secrets are generated for you, migrations run, and the wizard offers to start the server right away.

  3. Start it, and keep it running

    shell
    knwlge-enterprise start

    The first start enrolls the server with Global, prints the version and URL, and from then on sends the licence heartbeat and a short status report every couple of minutes. To run it as a service:

    shell
    knwlge-enterprise service install   # systemd on Linux, launchd on macOS
knwlge-enterprise status

  4. Confirm on the project page

    The project page in the Global App shows the server as enrolled, its version, and the health section: the database and storage checks, the allowed clients and sign-in methods, and a history graph of health, latency and storage — with a usage section beneath it charting prompts, briefs and tokens over time. When a newer server release exists it shows an update notice — the server logs it too, but never updates itself.

After enrollment

  • What leaves your infrastructure. The status report carries the version, whether the database and storage work, the allowed clients and sign-in methods, readiness checks, and numbers only for capacity and usage: the database's size, what the object store holds, the day's active people and connected clients, and — since the previous report — prompts captured, briefs served, knowledge items delivered, LLM tokens used and estimated tokens delivered and saved. The hourly heartbeat carries the licence state; the nightly export carries aggregate counts. Never prompts, code, repository names, user identifiers or credentials.
  • Licence and grace. The licence is a signed JWT re-issued on every heartbeat. If Global is unreachable the server keeps serving for a seven-day grace period before readiness fails, so an outage on our side never stops your developers. Neither the licence nor its grace runs past the enrollment key's valid-until date.
  • Enrollment keys. The server stays bound to the key it enrolled with. Deactivate that key, or let it pass its date, and Global refuses the server's heartbeats and reports until someone enters a new key on it — knwlge-enterprise enroll on the machine, or Settings → Knwlge Global in the server's console. Nothing else needs setting up again; the server keeps its identity. The project page says when Global is refusing a server.
  • Onboard developers. Point them at the CLI installation guide with your server's URL.
  • Upgrades. Install the new version (brew upgrade knwlge-enterprise or run the install script again), then knwlge-enterprise start — migrations run automatically. Take a database backup first when the release notes say a release includes migrations.
  • Kubernetes instead? The Helm chart in the Enterprise Server repository installs the same server with the same settings (KNWLGE_GLOBAL_URL, KNWLGE_GLOBAL_SERVER_URL, KNWLGE_GLOBAL_ENROLLMENT_TOKEN in the release Secret, heartbeat and usage-export cron jobs enabled). See docs/install-helm.md there.