A point-by-point look at KiCI — typed-TypeScript pipelines that run on your own infrastructure — versus CircleCI’s YAML pipelines on its cloud compute (or self-hosted runners).
Pipelines are real, typed TypeScript — loops, conditionals, functions, autocomplete
Pipelines are configured in a .circleci/config.yml YAML file in the repository
Org-wide CI across repos
Push model: one workflow repo defines jobs that run on events from every matching repo in your org — selected by a repos: glob, with nothing added to the source repos themselves
Each project imports the orb it needs into its own CircleCI configuration file
Source code and secrets
Your source and secrets stay on your own sovereign infrastructure; KiCI’s hosted control plane never receives them
Secrets are stored in CircleCI — keys are kept in the CircleCI web app, in project settings or a context, not in your repo
Self-hosting model
You self-host the whole execution environment — orchestrator and agents — on your own infrastructure, while KiCI runs the control plane as a managed service
Jobs run on CircleCI’s cloud compute by default; self-hosted runners let you run jobs on your own infrastructure instead
Autoscaling ephemeral agents
A built-in auto-scaler provisions ephemeral agents on demand across Docker/Podman containers, bare-metal processes, and Firecracker microVMs — on your own infrastructure, with no extra controller
Self-hosted autoscaling relies on Kubernetes — the container runner spins up more pods as work queues — or on cloud autoscaling groups you set up
Cost model
The hosted control plane is free with full functionality; paid tiers raise limits for scale and observability and never meter your executions — you provide the execution compute itself
CircleCI cloud compute is metered — each resource class has a credits-per-minute price; self-hosted runners shift that cost to your own infrastructure
Development experience
Testing & local dev loop
kici run --local and kici run remote run a full workflow from your current codebase — locally or against the real remote pipeline — including unstaged changes, with no commit or push
The CLI can run a single job locally with Docker, but not full workflows — broader runs go through CircleCI
Dynamic job generation
Generate jobs programmatically in-process — a dynamicJob generator emits typed job definitions in TypeScript, fanning out one job per item an upstream job discovers
Dynamic configuration uses a setup workflow — a setup config generates and continues the rest of the pipeline configuration at runtime
KiCI