Introduction
Manually updating applications in Kubernetes is almost always a pain: you need to track image tags, apply manifests on time, remember versioning rules, and avoid “bringing down” production. Keel solves this problem as a Kubernetes Operator: it monitors new container versions (and Helm releases) and automatically updates your workloads according to a defined policy — Deployments, DaemonSets, StatefulSets, and Helm releases.
Official repository: https://github.com/keel-hq/keel
What is Keel and how does it work
Keel is a lightweight self-hosted service (a single container, no separate database) that runs inside a cluster and acts as an “auto-updater.” Update management logic is defined directly in your application manifests (via annotations) or in Helm charts:
- what to update — a specific Deployment/StatefulSet/DaemonSet or a Helm release;
- when to update — via registry polling (poll) or a webhook trigger;
- how to update — according to a versioning policy (for example, patch/minor via SemVer) or forcefully.
The idea is simple: you publish a new image to the registry, Keel detects it and updates the resource while respecting the defined rules.
Table: quick commands and actions
| Task | Command / action | Notes |
|---|---|---|
| Create namespace | kubectl create namespace keel | Isolates Keel components |
| View Keel pods | kubectl -n keel get pods | Checks that Keel is running |
| View Keel Deployment | kubectl -n keel get deploy | Quick diagnostics |
| Apply application manifest | kubectl apply -f deployment.yaml | After adding Keel annotations |
| View namespace events | kubectl -n default get events --sort-by=.metadata.creationTimestamp | Helps understand what was updated and when |
| Check rollout | kubectl -n default rollout status deploy/webhook-demo | Convenient after image updates |
| Rollout history | kubectl -n default rollout history deploy/webhook-demo | Checks which revision was applied |
Practical usage examples
Example 1. Automatic Deployment updates via SemVer (minor)
Suppose you want to automatically pull new image versions, but only within the minor scope (for example, 1.3.x → 1.4.x, but not 2.0.0). Add Keel annotations to the Deployment manifest:
kind: Deployment
metadata:
name: webhook-demo
namespace: default
annotations:
keel.sh/policy: minor
keel.sh/trigger: poll
Example 2. Updating only patch versions (no minor “jumps”)
Suitable for production environments where minimizing risk is critical:
metadata:
annotations:
keel.sh/policy: patch
keel.sh/trigger: poll
Logic: 1.4.2 → 1.4.3 will update, while 1.4.2 → 1.5.0 will not.
Example 3. StatefulSet: careful updates for stateful services
Keel supports StatefulSets. This is useful when you frequently release new application builds but want to stay within strict versioning policies:
kind: StatefulSet
metadata:
name: api-stateful
annotations:
keel.sh/policy: patch
keel.sh/trigger: poll
spec:
serviceName: api-stateful
replicas: 3
selector:
matchLabels:
app: api-stateful
template:
metadata:
labels:
app: api-stateful
spec:
containers:
- name: api
image: your-registry.example.com/api:3.2.9
imagePullPolicy: Always
Example 4. DaemonSet: updating agents/loggers on all nodes
A classic use case — log agents, security agents, node-exporter, and any “one per node” services:
kind: DaemonSet
metadata:
name: log-agent
annotations:
keel.sh/policy: minor
keel.sh/trigger: poll
spec:
selector:
matchLabels:
app: log-agent
template:
metadata:
labels:
app: log-agent
spec:
containers:
- name: agent
image: your-registry.example.com/log-agent:0.9.1
imagePullPolicy: Always
Example 5. Helm: automatic release updates
Keel can also work as a “provider” for Helm. The practical logic is the same: you define update rules in the chart/values, and Keel updates the release when a new version appears (either of images or of the release itself, depending on your delivery model).
In practice, this is convenient if you have many similar environments (dev/stage) and want them to update automatically based on clear rules, without running helm upgrade manually every time.
Installing Keel in a cluster
Below is a basic, “quick start” scenario. For details and installation variations (including the Helm chart), refer to the Keel documentation and repository.
Step 1. Prepare the namespace
Step 2. Install Keel
Option A (Helm chart): if you prefer Helm-based installation, use the Keel chart. The general logic is:
helm repo update
helm install keel keel/keel -n keel
Note: the repository address/chart name may vary depending on the source. The safest approach is to verify the latest commands in the official documentation or on ArtifactHub.
Option B (kubectl apply): suitable if you want minimal dependency on Helm. In this case, apply the Keel YAML manifests from the official repository/documentation.
Step 3. Verify that Keel is running
kubectl -n keel get deploy
Step 4. Add annotations to your workloads
Keel starts working when it detects its annotations (policy/trigger, etc.) on resources. After adding them, apply the changes:
Operational recommendations
- Start with patch for production and use minor for dev/stage — this makes risk control easier.
- Use unique, predictable tags. If you rely on “latest,” updates can become opaque.
- Choose the right trigger: poll is simpler to start with; webhooks are faster and reduce registry queries.
- Observability: ensure you can see rollout events (events/logs) to quickly understand why an update happened or was skipped.
In practice: where this works best
Keel fits especially well in scenarios where you want “almost CI/CD” without heavy pipelines: small teams, product microservices, fast dev/stage cycles, and standardized environments. In such cases, simplicity and predictable updates matter more than added complexity.
If you run Kubernetes yourself (kubeadm/k3s) or maintain multiple environments for different projects, it’s convenient to have infrastructure where VPS instances can be provisioned quickly and predictably — for example, in a region close to your target audience. With Serverspace, you can deploy virtual servers in the desired location and build clusters the way you need (dev/stage/sandboxes), then use Keel to automate service updates with SemVer-based policies.
Keel in real-world workflows: reducing operational friction
One of the less obvious advantages of Keel is how it changes day-to-day operational habits. Instead of treating deployments as explicit actions (“someone needs to update the image”), updates become a predictable background process driven by rules. This shift reduces cognitive load: engineers stop thinking about how to roll out a new version and focus more on what they are shipping.
In teams where multiple services are updated independently, this approach helps avoid synchronization issues. Each workload follows its own update policy, so a minor change in one service does not force coordinated manual actions across the cluster. Over time, this leads to fewer rushed fixes, fewer “just update the tag quickly” moments, and more confidence in the release process.
Keel is also useful as a transitional tool. For teams that are not ready to invest in complex CI/CD pipelines or GitOps workflows, it provides a practical middle ground. You still get automated, policy-based updates, but without introducing additional infrastructure components or significantly changing existing processes. This makes Keel especially attractive for growing teams and projects that need automation now, not after a full platform redesign.
Conclusion
Keel is a practical Kubernetes Operator for automating updates of Deployments, StatefulSets, DaemonSets, and Helm releases. It’s ideal when you want to eliminate manual “kubectl apply just to change a tag” workflows and replace them with managed policies (patch/minor) and clear triggers. As a result, teams save time, delivery cycles become faster, and the risk of human error during frequent releases is reduced.
FAQ
Is Keel a replacement for CI/CD?
No. CI/CD typically handles building, testing, and publishing artifacts. Keel solves a narrower task: automatically updating Kubernetes workloads when a new image/version is already available, according to defined rules.
Which Kubernetes workload types are supported?
In a typical setup, Keel can update Deployments, StatefulSets, and DaemonSets, and it can also integrate with Helm releases.
How does Keel decide when to update?
This is defined via annotations: you choose a policy (for example, patch/minor via SemVer) and a trigger type (such as poll). If the new version matches the policy, Keel initiates the resource update.
What should I choose: poll or webhooks?
Poll is simpler to start with: Keel periodically checks the registry. Webhooks are useful when you need faster reaction to releases and want to reduce unnecessary registry queries.
Can Keel be used in multiple environments?
Yes. Keel is typically installed separately in each environment (dev/stage/prod), with different update policies — for example, minor for dev/stage and patch for production.
Where can I find examples and up-to-date parameters?
Start with the official repository and documentation: GitHub keel-hq/keel and keel.sh.
Additional resources: the Serverspace knowledge base and Kubernetes
If you are just getting started with Kubernetes or want to dive deeper into specific topics — from core concepts to day-to-day cluster operations — the Serverspace knowledge base already contains a wide range of materials dedicated to Kubernetes.
In the knowledge base, you can find:
- step-by-step guides for working with Kubernetes and containers;
- breakdowns of common DevOps and cluster administration tasks;
- tutorials on application deployment, networking, storage, and security;
- practical articles on Kubernetes ecosystem tools, from basic utilities to operators and automation.
These materials are convenient to use as a day-to-day reference: when you need to quickly recall a command, verify a configuration, or understand how to properly set up a specific component. Combined with tools like Keel, this helps not only automate updates but also build a clearer and more manageable Kubernetes infrastructure.