Settings

The settings page (/orgs/:customerId/settings) uses a tabbed layout:

General — displays the organization name (editable by owners via inline click-to-edit) and the organization ID
Members — team management with invite, role assignment, and member removal
Roles — custom role management with granular permission matrix
API keys — API key creation and revocation for dashboard/programmatic access
Orchestrator keys — orchestrator API key management for Platform WebSocket connections
Sources — read-only list of registered webhook sources (see below)
Billing — plan and payment management
CI trust — trust policy configuration for CI runs (visible with ci_trust:read permission)
Global workflows — org-level security knobs for cross-repo workflows (visible with org_settings:read permission)
Webhooks — outbound webhook endpoint management with delivery logs and test ping
Event log — inbound webhook delivery log (visible with event_log:read permission)
Security — read-only view of the orchestrator’s dashboard-write policy matrix (visible with org_settings:read permission)
Support access — opt-in switch that controls whether KiCI support staff may open read-only support sessions against your org (visible with support:read; toggled with support:admin)

Audit-log-style entries are not a settings tab; they live on the dedicated Activity page accessible from the sidebar.

Tab selection syncs with the URL path (/settings/members, /settings/api-keys, etc.), making tabs bookmarkable.

General

General settings show your organization’s basic information, including the org name (editable by owners) and the unique organization ID. Use this to rename your org or reference the ID for API calls and configuration.

Members

The members tab lets you manage your team:

Invite new members by email.
Assign roles.
Suspend or remove members.
Configure per-user CI trust levels.

Each member’s linked provider accounts (e.g. GitHub) are also visible here.

Roles

Roles define granular permissions across 15 resource categories (runs, secrets, members, etc.) with 5 access levels: none, read, read_payload, write, admin.

Create custom roles to restrict what team members can do, or use the built-in Owner role for full access.

Teams

Teams are named groups of organization members. A role granted to a team is inherited by every member, so you can manage permissions for a whole group in one place.

Team names can also be referenced in workflow approval gates (requireApproval: [{ team: 'leads' }]) — any member of the named team can satisfy that gate.

Managing teams (create / rename / delete, membership, role grants) requires the Teams permission at admin; read shows a view-only list.

API keys

API keys allow programmatic access to the KiCI API for automation, scripts, and CI integrations.

Each key is scoped to this organization with a custom permission matrix and an optional expiry date. Keys can be revoked individually.

Use a key’s clone button to open the creation modal prefilled with that key’s name, expiry, and permissions — handy for recreating an expired key or deriving a new key from an existing one.

Orchestrator keys

Orchestrator keys authenticate the WebSocket connection between your orchestrator and the KiCI Platform relay.

Create a key here and set it as the KICI_PLATFORM_TOKEN environment variable in your orchestrator configuration. Keys can optionally be restricted to specific routing patterns.

Use a key’s clone button to open the creation modal prefilled with that key’s name and description.

The orchestrator keys tab manages API keys used to authenticate orchestrator-to-Platform WebSocket connections. These are separate from user API keys (which grant dashboard/API access).

List view — shows all active orchestrator keys with name, description, key prefix, creation date, and last used date.

Create — opens a modal to enter a name and optional description. After creation, the raw key is shown once in a copyable box. Set this key as the KICI_PLATFORM_TOKEN environment variable in your orchestrator configuration.

Revoke — opens a confirmation modal before soft-deleting the key. Any orchestrators using the revoked key will be disconnected.

Sources

Webhook sources are registered automatically when an orchestrator connects to the Platform.

Each source shows its routing key and full webhook URL — configure this URL in your provider’s webhook settings (e.g. GitHub App).

To retrieve the webhook secret for signature verification, use the kici-admin source get-webhook-secret <routingKey> command shown below each source.

The sources tab shows webhook sources registered by connected orchestrators. Sources appear here automatically when an orchestrator connects to the Platform — there is no manual “add source” action in the UI.

Each source displays:

Routing key — the source identifier (e.g., github:12345 for a GitHub App, generic:my-source for a generic webhook)
Webhook URL — the URL to configure in your provider’s webhook settings
Registered at — when the orchestrator first registered this source
Copy button — copies the webhook URL to the clipboard

Read-only — sources cannot be created, edited, or deleted from the dashboard. They are managed entirely by orchestrator connections. When an orchestrator disconnects, its sources remain visible (they are not automatically removed).

Empty state — if no orchestrator has connected yet, the tab shows “No webhook sources registered” with a link to the operator setup guide.

Webhook secrets — webhook secrets are not visible in the dashboard. They are configured on the orchestrator (see the operator guide), never in the dashboard, and are used to verify incoming webhook signatures.

Adding a new source requires:

Configure a new provider in the orchestrator (e.g., add a GitHub App to the orchestrator’s provider config)
Configure the webhook secret on the orchestrator (see the operator guide)
Restart the orchestrator — it will register the new source with the Platform on connection
Configure the webhook URL (shown in the sources tab) in the provider’s settings (e.g., GitHub App webhook URL)

Billing

The billing tab shows your current plan (Free, Pro, or Team), resource usage meters, and lets you upgrade to a paid tier.

Choose Monthly or Annual billing, click “Upgrade to Pro” or “Upgrade to Team” to start a Stripe Checkout, or use “Manage payment” to switch tiers and update payment methods via the Stripe Billing Portal.

The usage meters track:

Members: invited users in this org.
Orchestrator connections: direct WebSocket connections from your orchestrators to the Platform. Only coordinators (and standalone orchestrators) open a connection; peer/worker nodes in a Raft cluster share their coordinator’s connection and don’t count separately.
Relayed webhooks (this month): webhooks delivered through the Platform relay during the current billing window.
Live log minutes (today): live-log streaming time consumed in the current UTC day. On the Free tier this is capped at 60 minutes/day. Paid tiers have no daily cap; instead a rolling-24h fair-use limit applies (Pro 5,000 / Team 20,000 / Business 50,000 tail-minutes per day). Only live tailing of a running job counts — stored and completed-run logs are never metered.
Retention period: how long execution history is kept.

The diagnostics page may show a higher orchestrator count than this tab — diagnostics counts cluster nodes, billing counts billable connections.

The orchestrator-connections counter measures the number of direct WebSocket connections that your orchestrator processes hold open against the KiCI Platform — one count per live connection.

What counts as one connection:

One standalone orchestrator (single process, no cluster) → 1 connection.
One Raft cluster (1 coordinator + N peers) → 1 connection — only the coordinator opens a Platform WebSocket. The peers gossip through the coordinator and never connect to Platform directly, so they do not count toward your billing limit.
N independent orchestrator deployments (e.g., one per environment, one per region) → N connections.

This is why the diagnostics page can show more orchestrator nodes than the billing page shows connections: diagnostics counts every node in your topology (coordinator + peers), while billing only counts the WebSocket connections you pay for. A 4-connection org running two 3-node clusters and two standalones will show 4 on the billing meter and 8 on the diagnostics page — both numbers are correct, they measure different things.

When you hit the cap, the next coordinator that tries to connect is rejected; your orchestrator logs a plan-limit error. Existing connections are never disconnected. Upgrade your plan to lift the cap; the meter updates immediately.

The relayed-webhooks counter only includes webhooks delivered through the KiCI Platform relay — the route at kici.dev that verifies an inbound webhook and forwards it to your orchestrator.

Webhooks pointed directly at your orchestrator’s public ingest endpoint never reach the Platform, so they’re invisible to this counter and uncapped on every Hosted tier. If you have a public orchestrator ingress, you can mix-and-match: use the relay for sources you can’t expose publicly, and point GitHub (or any provider / generic webhook) straight at your orchestrator for the rest.

Every webhook the relay forwards counts — including ones your workflows ultimately ignore. Trigger matching runs on your orchestrator, not on the Platform, so the relay forwards each verified webhook before any trigger is evaluated. A source that sends many events you filter down to a handful of runs still consumes one relayed webhook per event. If a high-volume source mostly produces no run, point it directly at your orchestrator (see above) to keep it off this counter entirely.

When you hit the cap, new relayed webhooks are rejected with 429 Plan limit reached. Upgrade in the Stripe Billing Portal to lift the cap immediately; usage resets monthly on your billing anniversary.

Switch the prices shown on the tier cards between US dollars and euros. The choice you pick here is also the currency Stripe charges in when you click “Upgrade”.

The default is detected from your browser language. EU, EFTA, and UK locales default to euros; everywhere else defaults to dollars.

Your choice persists in a 90-day cookie (kici_pricing_currency), so it survives across reloads and applies on every billing page.

This banner appears when your organization’s latest payment to Stripe has failed. Your subscription remains active during the retry period, but you should update your payment method promptly to avoid service interruption.

CI trust

CI trust policy controls how your organization handles PR-triggered runs from different contributor types. Configure the default trust level for unknown contributors and set per-member overrides to control who can run workflows with full secrets access.

Global workflows

Global workflows let a single “workflow repo” define jobs that run when events happen in other repos in the same org.

This tab exposes the security knobs as independent axes:

Master enable toggle: turn the whole feature on or off.
Authoring allow-list: which repos may define global workflows.
Source deny-list: source repos whose events never trigger globals (forks, public-contrib).
Elevated-access list: authoring repos that need source-repo secrets during execution.

See the user guide and the architecture reference for the full model.

Master kill-switch for global workflows in this org.

OFF: the orchestrator will not register any workflow that declares repos: patterns, and will not dispatch cross-repo triggers — effectively rolling the org back to per-repo-only semantics. All other settings on this page are ignored.
ON: the other toggles become your safety rails. Turn ON to opt in.

Restricts which repos in this org may define global workflows (the “authoring axis”).

OFF: any repo in the org may declare a workflow with repos: patterns and have it registered.
ON: only repos whose identifier matches one of the entries below may author globals. Non-matching repos have their global workflows dropped at registration time, with a warning in the orchestrator log.
ON + empty list: no repo may author globals — use as a temporary lock-down.

Each entry has two parts:

Source: pick a configured source (a specific GitHub App or universal-git source) to pin the entry to that source only, or leave it as Any source to match across every source in the org.
Pattern: a glob matched against the authoring repo identifier (e.g. myorg/ci-*, myorg/platform-*).

Pinning by source is useful when the same owner/repo could legitimately exist on more than one configured source and you only want to trust one of them as an author.

Deny-list for source repos whose events must never trigger a global workflow (the “source axis”).

Use this for untrusted territory — forks, public-contrib mirrors, sandboxes — where a single push shouldn’t be able to fan out org-wide automation.

Evaluated at dispatch time against the repo that emitted the event, independently of the authoring allow-list: a global workflow whose author is allowed will still be skipped if the source repo is denied. Both lists can be active simultaneously.

Each entry has two parts:

Source: pick a configured source to deny only events delivered on that source, or leave it as Any source to deny across the org.
Pattern: a glob matched against the source repo identifier (e.g. myorg/fork-*, myorg/public-*).

Pinning by source is the right move when the same owner/repo is reachable through more than one configured source (e.g. a public forge and a trusted mirror) and you want to drop deliveries from only one of them.

Authoring repos listed here receive elevated access to source-repo secrets during global workflow execution.

Without elevation: a global workflow job runs with only the workflow repo’s own credentials — it can clone both repos but can’t read the source repo’s scoped secrets.
With elevation: the job gets the source repo’s secret context injected, so deploy / release / cross-repo automation flows work.

Treat elevated repos as effective owners of every source repo’s CI secrets — only add repos you fully trust.

Each entry has two parts:

Source: pick a configured source to elevate only when the authoring repo lives on that source, or leave it as Any source to elevate across the org.
Pattern: a glob matched against the workflow-authoring repo, not the source repo (e.g. myorg/ci-deploy, myorg/release-automation).

Pinning by source narrows the trust window: if the same owner/repo is configured on more than one source, only the source you pick will grant elevation.

Webhooks

Configure outbound webhook endpoints to receive notifications when runs and jobs change status. Each endpoint receives HMAC-SHA256 signed payloads with event details.

For each endpoint you can:

Subscribe to event types: run.started, run.completed, run.failed, job.started, job.completed, job.failed.
View delivery logs: HTTP response codes and retry counts.
Send a test ping: verify connectivity before going live.

The delivery log shows recent webhook deliveries for an endpoint, including the HTTP status code, number of retry attempts, and the event payload.

Retry behavior:

Deliveries are retried up to 3 times with exponential backoff.
After 10 consecutive failures, the endpoint is automatically disabled — you can re-enable it from this view.

Event log

The event log shows every inbound webhook this organization has received, regardless of whether it came in via the Platform relay or directly to an orchestrator.

Each row shows the inbound webhook’s metadata and, with the right permission, its raw payload and processing outcome.

Filter by routing key, event type, status, or delivery ID. Click a row for the full detail plus the payload viewer.

The detail panel shows the inbound webhook’s full record:

Delivery: where the webhook arrived and how it was routed.
Outcome: what happened next — the matched workflow count and links to any runs it spawned.
Payload: the raw webhook body, loaded on demand. Requires event_log:read_payload.

Oversized payloads show an “omitted” badge.

The event log tab (/orgs/:customerId/settings/event-log) shows every inbound webhook this organization has received. The event log records, for each delivery: routing key, event, action, repo, status, processing outcome (processed / duplicate / lockfile_missing / failed), the matched workflow count, and the first run spawned (if any).

The list view supports filters for routing key, event type, status, and free-text delivery ID search. Click a row to open a detail panel with the full delivery record plus the payload viewer.

Permissions:

event_log:read — list rows and view metadata in the detail panel.
event_log:read_payload — additionally view the raw webhook payload body. (Owners and admins inherit this. Lower-tier roles see “Payload not available” with a hint to ask for an elevated role.)

Edge cases the UI surfaces:

Payload omitted — when the inbound payload exceeded the configured size cap, the row is still recorded with the payload shown as “omitted”.
Orchestrator unavailable — when the orchestrator does not respond in time, the list still loads with the delivery metadata only, marked with an orchestrator unavailable banner.
Orchestrator-only deliveries — direct-ingress deliveries that never crossed the Platform appear marked orchestrator_only.

Retention is 30 days.

Security

Read-only view of the orchestrator’s dashboard-write policy.

Each row toggles one mutating dashboard action — setting a secret, approving a held run, retrying a dead-lettered webhook, and so on. The orchestrator operator decides which actions stay on the dashboard and which become CLI-only. The dashboard cannot change the policy itself — that’s the point: disabled actions stay off the dashboard entirely.

Manage the policy with:

Show the full policy: kici-admin org-settings dashboard-writes show
Disable an operation: kici-admin org-settings dashboard-writes set --op <name>=false
Reset to permissive defaults: kici-admin org-settings dashboard-writes reset

The summary strip at the top shows total / enabled / disabled counts plus whether your orchestrator is currently connected. A disconnected orchestrator means the page falls back to the cached policy from the most recent connection.

Support access

Controls whether KiCI support staff may open read-only support sessions against your organization. Sessions are off by default — nobody outside your org can read your data until you opt in here.

When enabled:

KiCI staff can open time-boxed, read-only sessions to investigate an issue.
Every read they perform is recorded in your audit trail with the support reason.
No writes are ever possible during a session.

Disabling the toggle immediately ends any in-progress support session. Only users with the support:admin permission (owners by default) can change this setting.

The Support access tab controls whether KiCI support staff may open a read-only support session against your organization to help diagnose an issue. The setting is off by default — until you opt in here, no one outside your org can read your data.

When support access is enabled:

A KiCI operator can open a time-boxed (30-minute, renewable), read-only support session scoped to a stated reason.
A support session is runs-only: the operator can browse your run list and, by confirming each run individually, view that run’s detail and step logs. Nothing else is visible, and no write is ever possible.
Every run an operator opens is recorded in your Activity audit trail, attributed to the operator with the support reason — so you can see exactly what was looked at and why.

Disabling immediately ends any active session. Toggling the switch off closes every in-progress support session for your org at once. Enabling and disabling the setting is itself audited, attributed to the user who changed it.

Viewing the setting requires the support:read permission; changing it requires support:admin (granted to owners by default).