Documentation
KICK restarts a workload when a Secret or ConfigMap it consumes changes —
but only when the running rollout is actually stale, and only when your GitOps
tool permits the restart. GitOps gating is optional: KICK also runs on a cluster
with no GitOps controller at all.
What is KICK?
Kubernetes never restarts a Pod when a Secret or ConfigMap it reads changes,
so the running Pod silently drifts from its intended configuration. KICK is a
small operator that closes this gap: it discovers each workload’s dependencies,
detects relevant changes, checks that the running rollout predates the change,
optionally asks your GitOps tool for permission, and then issues exactly one
restart via the standard kubectl.kubernetes.io/restartedAt annotation. It
injects no state into your workloads.
Where to start
- Install KICK with Helm (or from source for local dev).
- Run the Quickstart to see a Secret change restart a Deployment.
- Read Concepts to understand discovery, freshness, and GitOps gating.
- Look up fields in the Reference.
Sections
| Section | What you’ll find |
|---|---|
| Installation | Install KICK with Helm or from source |
| Quickstart | Watch KICK restart a Deployment on Kind |
| Concepts | Discovery, freshness, and GitOps gating, explained |
| Comparison | How KICK differs from Reloader and Wave |
| Guides | Argo CD, Kargo, running without GitOps, External Secrets, troubleshooting |
| Reference | KickPolicy / KickRequest / NotificationPolicy API, metrics, events, config |
| Operations | RBAC, security, scalability, upgrades |
| Theory | The formal operator model in scientific notation |
| Development | Debugging, the timeline UI, workflow |
| For AI Agents | llms.txt, Markdown output, agent instructions |
| Decisions | Architecture decision records |