CI/CD and environment delivery

test and live have isolated API keys, customer data, and active configuration versions. Treat configuration like application code: review source, validate it, exercise representative events in test, and require explicit production approval.

Understand the credentials

Keep administrative credentials separate from ingestion keys. Store secrets in protected CI environments, not .kite/config.json or source control.

Validate pull requests

Pin the CLI version through your lockfile and validate the authored project:

name: Kite config
on: [pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: pnpm/action-setup@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: pnpm
      - run: pnpm install --frozen-lockfile
      - run: pnpm exec kite validate --strict --json

kite validate does not accept --env; compilation uses defaultEnvironment from .kite/config.json. deploy and config diff can compile for an explicit target. Avoid environment-dependent source when possible, and verify the project default when it is unavoidable.

Run producer contract tests in the same pull request. For historical definition changes, deploy the branch to test and attach the dry-run artifact with aggregate impact and per-customer diffs:

kite recompute --all --dry-run --env test --json

Deploy and exercise test

kite validate --strict
kite config diff --env test
kite deploy --env test --json
kite config versions --env test --json

Capture the exact deployed test version from machine-readable output. Then exercise the model:

kite events send account.created --customer ci_example --env test
kite events send feature.used --customer ci_example \
  --props '{"feature":"reports"}' --env test
kite customers inspect ci_example --env test
kite journeys inspect ci_example onboarding --env test
kite health explain ci_example --env test
kite rules logs --customer ci_example --detail --env test

Use a dedicated synthetic customer ID and retain validation, diff, deploy, and inspection output as workflow artifacts.

Promote an immutable version

Promote the exact version tested above:

kite config diff v11 v12 --env test
kite config promote --version v12
kite config versions --env live

Promotion copies the stored test snapshot and hash to a new live version. It does not recompile local files. GitHub Actions provenance is preserved and includes repository, commit, ref, workflow, actor, and run metadata when available.

Deployment uses an optimistic active-version check. If another deployment wins the race, review the new diff and retry instead of bypassing the conflict.

Roll back

Inspect the live versions and diff before activating an older one:

kite config versions --env live
kite config diff v12 v13 --env live
kite config rollback --env live --version v12

Rollback changes the definition used for future evaluation. It does not remove raw events or automatically rebuild existing state.

kite recompute --all --dry-run --env live
kite recompute --all --env live

A persisted global recompute requires confirmation. Unlike live deploy and promotion, config rollback --yes bypasses its standard confirmation, so do not use it casually in automation.

Audit and recovery

kite config pull --version v12 --env live

config pull writes an immutable compiled snapshot to .kite/pulled-config.json; it does not round-trip back into TypeScript source. Use it for audits and debugging.

Store these release artifacts:

• validation JSON;
• local-to-target diff;
• deployed or promoted version and hash;
• representative inspection output;
• dry-run recompute summary when semantics changed.

See Backfill and recomputation before rebuilding a large environment.