A point-by-point look at KiCI — typed-TypeScript pipelines on infrastructure you control — versus GitHub Actions’ YAML workflows on GitHub-hosted or self-hosted runners.
Pipelines are real, typed TypeScript — loops, conditionals, functions, autocomplete
Workflows are authored in YAML, and custom actions are composite (YAML) or JavaScript actions
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
Reusable workflows are called from another workflow with the uses keyword
Source code and secrets
Your source and secrets stay on your own sovereign infrastructure; KiCI’s hosted control plane never receives them
Your source lives on GitHub, and Actions secrets are uploaded to GitHub — which decrypts them to inject into the workflow runtime
Self-hosted execution model
The whole execution environment — orchestrator and agents — is self-hosted and sovereign on your own infrastructure; KiCI operates only the hosted control plane
Self-hosted runners execute jobs on machines you deploy and manage, while the workflow orchestration stays on GitHub
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
Autoscaling self-hosted runners needs a separate Kubernetes controller — Actions Runner Controller (ARC) — or you rely on GitHub’s managed cloud runners
Cost model
The hosted control plane is free with full functionality; paid tiers raise observability and usage limits (retention, members, orchestrators) for scale and experience — they never meter your executions, so the cost never grows with how much CI you run. You provide the execution compute itself.
Self-hosted runner usage is free (you supply and run the machines); GitHub-hosted runner minutes are metered and billed per minute
Development experience
Testing & local dev loop
kici run --local and kici run remote trigger a workflow straight from your current codebase — including unstaged changes — so you get a result without committing or pushing
Workflows run on runners when triggered by a repository event, so iterating means committing the change, pushing it to GitHub, then waiting for a runner to pick up and finish the run before you can see the result — every tweak repeats that round trip
Dynamic job generation
Generate jobs programmatically at runtime — a dynamicJob generator emits job definitions in TypeScript, fanning out one job per item an upstream job discovers (beyond static and dynamic matrices)
Dynamic behavior is matrix-bounded — a job’s matrix can be generated from another job’s JSON output (via fromJSON), expanding one job into combinations
Typed values between steps & jobs
Step and job outputs are declared with Zod schemas, so values passed between jobs are typed and validated — not stringly-typed
KiCI