---
title: "Keel - automated Kubernetes updates | WebhookRelay"
meta:
  "og:description": "Automatically update kubernetes deployments on image push"
  "og:title": "Keel - automated Kubernetes updates"
  description: "Automatically update kubernetes deployments on image push"
---

![Stripes](https://webhookrelay.com/blog/introducing-keel/images/stripes.svg)

# **Keel - automated Kubernetes updates**

Automatically update kubernetes deployments on image push

![keel overview](https://webhookrelay.com/blog/introducing-keel/images/keel-overview.png)

## [Synopsis](#synopsis)

If you are using Kubernetes for dev/test/production - you need a way to automate deployment updates once new images are available. Keel is a lightweight service to take care of that.

You can find more on its website: [https://keel.sh](https://keel.sh) and Github repository [https://github.com/keel-hq/keel](https://github.com/keel-hq/keel).

---

While [Container Builder](https://cloud.google.com/container-builder/docs/) and [Google Container Engine (Kubernetes)](https://cloud.google.com/container-engine/) make a great pair and building images and running your workloads - there is a missing gap: who/what updates deployments when new images are available? maybe it's you:

1. update image tag in `deployment.yaml`
2. run `kubectl apply -f deployment.yaml`

It does feel good to do that rolling update for the first few times, but what if you don't have access to _kubectl_ or simply you are making lots of releases?

These updates feel too repetitive and simply not necessary. This is what Keel solves: pluggable trigger system (webhooks, pubsub, polling) and pluggable provider system (Kubernetes, Helm).

## [Keel overview](#keel-overview)

Keel acts as a native Kubernetes service, main features:

- Runs silently and doesn't require direct interactions from the user (users label deployments that are eligible for updates)
- Automatically creates topic & subscriptions for your GCR images (GCR uses pubsub instead of webhooks to notify regarding push/delete events in registry) so you don't have to
- Accepts webhooks from DockerHub, Quay, JFrog (because not everyone runs on Google Cloud)
- Schedules regular image SHA digest checks if you don't have access to webhooks (ie: repository is not yours) and scans for new tags

So, once you have deployed Keel in your Kubernetes cluster, the workflow looks like this:

1. Tag a release in GitHub
2. Cloudbuild/{insert your favorite builder here} starts building an image
3. Keel gets new image event, looks for impacted deployments marked with keel update policy and starts rolling update

Easy! Sounds like a PaaS, right?

If you have any questions - you can often find me on k8s Slack channel: [kubernetes.slack.com](https://kubernetes.slack.com) look for @karolis