// the find
flant/shell-operator
Shell-operator is a tool for running event-driven scripts in a Kubernetes cluster
Shell-operator runs shell scripts as Kubernetes event-driven hooks — watch a resource, get called on add/update/delete. It's the escape hatch for ops teams who need cluster automation without writing a full Go operator. Used in production at Deckhouse and KubeSphere at real scale.
- The binding config model is genuinely clever: hooks declare their triggers via stdout JSON/YAML, so the operator framework stays decoupled from the script logic entirely.
- Supports validating and mutating admission webhooks from shell scripts — not just reconciliation loops. Most operator frameworks make this painful even in Go.
- Object filter with jq support means you can avoid noisy re-triggers when only irrelevant fields change, which is the thing that kills naive watchers in production.
- Active maintenance (last push yesterday), real-world production validation via Deckhouse, and solid example coverage including CRDs, secrets, schedules, and webhook patterns.
- Shell as the implementation language is the core tradeoff: error handling, retries, and idempotency are entirely on you. A buggy hook that half-applies changes and crashes leaves you with no rollback story.
- No built-in state beyond what you can stash in ConfigMaps or environment — complex operators that need to track multi-step workflows will hit this ceiling fast.
- Hook concurrency and ordering guarantees are limited; if two events fire simultaneously for different resources and your hook has side effects, you're responsible for your own locking.
- 2.6k stars for a 7-year-old project used in a Kubernetes platform suggests it solved a niche problem well but hasn't broken into general adoption — the community is thin outside the Flant/Deckhouse ecosystem.