DEV.co
Open-Source DevOps · flant

shell-operator

Shell-operator is a Kubernetes tool that lets you run event-driven scripts (bash, python, etc.) to respond to cluster changes. It bridges the gap between familiar shell scripts and Kubernetes operators, making it easier for operations teams to automate cluster management without learning Go.

Source: GitHub — github.com/flant/shell-operator
2.6k
GitHub stars
253
Forks
Go
Primary language
Apache-2.0
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
Repositoryflant/shell-operator
Ownerflant
Primary languageGo
LicenseApache-2.0 — OSI-approved
Stars2.6k
Forks253
Open issues71
Latest releasev1.20.1 (2026-06-30)
Last updated2026-07-08
Sourcehttps://github.com/flant/shell-operator

What shell-operator is

Shell-operator is a Go-based Kubernetes operator framework that triggers shell/python hooks on object events (add/update/delete), supports object selectors and property filters, and provides validating and conversion webhook machinery. Hooks define bindings via JSON/YAML on stdout, decoupling script logic from operator infrastructure.

Quickstart

Get the shell-operator source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/flant/shell-operator.gitcd shell-operator# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Cluster automation for ops-familiar teams

Teams comfortable with bash/python but unfamiliar with Go can automate cluster-wide tasks (resource provisioning, configuration, cleanup) using existing tooling and knowledge.

Custom admission webhooks and resource conversion

Implement validating webhooks and custom resource version conversion logic in shell without writing Go controllers or deploying separate webhook services.

Foundation for platform automation (Kubernetes distribution)

Used in Deckhouse and KubeSphere as core technology to extend and configure Kubernetes features via declarative hook bindings, supporting GitOps workflows.

Implementation considerations

  • Hooks must define bindings in JSON/YAML on stdout; script logic must emit properly formatted binding metadata before performing actions.
  • RBAC and service account permissions must be carefully scoped for each operator instance; oversized roles create security attack surface.
  • Script failures (non-zero exit codes) halt hook processing; implement robust error handling and logging for troubleshooting in production clusters.
  • Container image must include bash/python/kubectl and any dependencies; layer custom tooling into deployment or use init-containers for preparation.
  • Event ordering and idempotency are operator responsibilities; scripts must handle re-triggers and concurrent hook invocations safely.

When to avoid it — and what to weigh

  • Performance-critical event processing — Shell script overhead and serialization/deserialization of Kubernetes objects for each hook invocation may not suit high-frequency event scenarios requiring low latency.
  • Complex state management or distributed coordination — Shell-operator handles stateless hook execution; applications requiring persistent operator state, leader election, or multi-instance coordination should use Go-based operators.
  • Requirement for built-in operators for specific software — Shell-operator is a framework, not an operator for databases, message queues, or other products. Use domain-specific operators (e.g., prometheus-operator, kafka-operator) if available.
  • Air-gapped or highly restricted environments without script capability — Deployment requires ability to execute arbitrary scripts; restricted policy environments may prohibit or complicate this security model.

License & commercial use

Apache License 2.0. Permissive OSI license allowing commercial use, modification, and distribution with attribution and liability disclaimer. Full license terms in LICENSE file.

Apache 2.0 permits commercial deployment, modification, and redistribution. No source code publication or license propagation required for proprietary applications embedding or extending shell-operator. Attribution recommended. Consult legal team for specific warranty/liability implications in your use case.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationStrong
License clarityClear
Deployment complexityModerate
DEV.co fitGood
Assessment confidenceHigh
Security considerations

Shell-operator executes arbitrary scripts in the operator pod; script supply chain security and input validation are critical. RBAC must restrict service account to minimal permissions (avoid cluster-admin). Webhook endpoints require TLS and API server authentication. Script failures or infinite loops can starve pod resources. No built-in secret rotation or encryption; rely on Kubernetes secret management and pod security policies.

Alternatives to consider

Kubebuilder / Operator SDK (Go)

Full-featured operator frameworks for teams comfortable with Go; stronger typing, better performance, and mature ecosystem for complex stateful operators.

Helm + post-install hooks / templates

Simpler for package-based deployments and config management; no operator lifecycle overhead, but less dynamic event-driven automation.

Kyverno / CEL-based policy engines

Native Kubernetes admission policy alternative if use case is validating webhooks and policy enforcement; no script execution required.

Software development agency

Build on shell-operator with DEV.co software developers

Evaluate shell-operator for your team. Test hook bindings, review RBAC requirements, and prototype with a sample use case in a dev cluster.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

shell-operator FAQ

Do I need to write Go to use shell-operator?
No. You write hook bindings (JSON/YAML) and scripts (bash, python, etc.). The operator runtime (Go) is pre-built in the container image.
How does shell-operator differ from addon-operator?
Shell-operator is the core framework for event-driven scripts. Addon-operator extends it with Helm chart support, value storage, and module lifecycle management for distribution-style operators.
Can I use shell-operator for validating webhooks?
Yes. Shell-operator provides hook machinery for validating webhooks (admission control). Hooks receive AdmissionReview objects and return validation decisions.
What are the performance limits?
Unknown from data. Depends on script complexity, object cardinality, and event frequency. Test in staging with your workload. Shell overhead may not suit millisecond-scale event processing.

Software developers & web developers for hire

DEV.co helps companies turn open-source tools like shell-operator into production software. Our software development services cover the full lifecycle — architecture, web development, integration, and maintenance — delivered by software developers and web developers who ship. Engage our software development agency to implement or customize it for your open-source devops stack.

Ready to automate your Kubernetes cluster?

Evaluate shell-operator for your team. Test hook bindings, review RBAC requirements, and prototype with a sample use case in a dev cluster.