Skip to content

Your tenant

Every Capacitor customer gets a managed instance at https://<your-github-org>.kcap.ai. This page is for the admin doing the one-time setup — installing the GitHub App and confirming your team can sign in. Individual contributors can skip ahead to Install the CLI.

Kurrent provisions your tenant and sends you a URL of the form:

https://acme.kcap.ai

…where acme is your GitHub org login. Until the GitHub App is installed, the tenant exists but no one can sign in.

Open the public listing and click Install:

https://github.com/apps/kurrent-kcap

Select the org that matches your tenant subdomain. You can grant access to all repositories or to a specific subset; either is fine — Capacitor only reads metadata (repo name, default branch, PR title) and never modifies your code.

The install grants Capacitor:

  • Read-only repository metadata for repos you select
  • Read access to organization members and teams so the share picker can target real people
  • Read access to pull requests so kcap review can correlate sessions to PRs

There is no per-tenant client secret to copy. The GitHub App is shared across all Kurrent-hosted tenants and the auth proxy holds the credentials; you only authorise the install.

Open your tenant URL. You’ll be redirected to GitHub to authorise the OAuth flow:

https://acme.kcap.ai

Anyone in the org you authorised in step 2 can sign in. There is no separate user provisioning step — membership in the GitHub org is the gate.

GitHub org owners (role: admin in your org membership) are automatically Capacitor admins. They see a Server Settings item in the user menu and can configure runtime settings (eval runner credentials, embedding provider, Slack integration) at /admin/settings.

If your GitHub user isn’t an org owner but should be a Capacitor admin (break-glass), ask Kurrent to add your GitHub numeric ID to the tenant’s Auth:Admin:GitHubIds list.

5. Configure API keys for evals and embeddings

Section titled “5. Configure API keys for evals and embeddings”

Two server-side features need third-party LLM credentials before they work: the eval runner and the embedding service. Both are configured at /admin/settings — open the dropdown behind your avatar in the top-right and choose Server settings. Both are gated to admins.

  • Eval runner (/admin/settings → Eval runner). Lets users dispatch evaluations from the dashboard without running a local daemon. Add an Anthropic and/or OpenAI API key plus a judge model. Without this, dashboard evals can only run on a user’s own daemon, which means reviewers without a local Claude/Codex install can’t trigger them. See the Eval runner walkthrough.
  • Embeddings (/admin/settings → Embeddings). Powers judge-fact clustering on the Curation tab and the SessionStart guideline injection that feeds curated guidance back into future sessions. Pick a provider (Voyage or OpenAI) and supply the API key plus model. Without this, evaluation findings are still stored but never cluster, the Curation tab stays empty, and Claude won’t pick up curated guidance at session start. See Embeddings & guidelines.

Keys are stored encrypted at rest. You can configure either feature independently; neither is required to sign in or run sessions, but both are recommended for any team intending to use evals.

If you want session links posted into Slack to expand into a card showing repo, summary, and ownership, follow the in-app wizard at /admin/slack. The whole flow takes about 90 seconds: it generates a Slack app manifest pre-filled for your tenant, you create an app from it in your Slack workspace, click Install to <Workspace> in OAuth & Permissions so Slack issues a bot token, then paste the Signing Secret and Bot User OAuth Token back into the wizard. See the Slack admin walkthrough for the detailed step-by-step.

Slack is optional. Skip it now; come back later.

You’re done. Teammates don’t need the tenant URL to sign in — once a member of your GitHub org runs kcap setup, the CLI discovers your tenant automatically. Point them at Install the CLI.