NOTE: I renamed Quay Imager to Image Hooks, links have been updated.

Short post to introduce a tiny service called “quay-imager”.

This is an HTTP server that receives Webhook notifications and automates editing of a YAML file, by replacing an image reference.

How does this work?

Service Interactions


This is packaged and deployed as a Kubernetes deployment.

Before deploying the release, you will need to do some minimal configuration.

Then deploy the release.

$ kubectl apply -f

NOTE: There’s nothing in this code that requires to be run in a Kubernetes cluster, so you are free to build and deploy in other ways, for example Heroku.


Given this configuration:

  - name: < username>/< repository>
    sourceRepo: <github user>/<github repository>
    sourceBranch: master
    filePath: deploy/deployment.yaml
    updateKey: spec.template.spec.containers.0.image
    branchGenerateName: repo-imager-

This is an array of repositories, the name is used to match on the incoming webhooks

The sourceRepo and sourceBranch reference the file to be updated, the filePath is the actual file to change.

The updateKey is a JSON path to update with the incoming key.

Finally, the branchGenerateName is used to generate a random branch name. configuration

You’ll need to expose your service so it can be accessed by, and create a Webhook Notification for your repository.

This must be a “Push to Repository” notification, with a type of “Webhook POST”.

Configuring a Webhook

Fill in the Webhook URL with with the exposed URL (don’t forget things like ngrok if you’re testing this locally).

Finally, push an image to

$ docker push< username>/< repository>:v1

This should trigger an update to the GitHub repository, creating a new branch (named with the prefix repo-imager-), and opening a PR with the change.

The spec.template.spec.containers.0.image field, in the deploy/deployment.yaml field is updated with the image that was pushed, for example, above, this would be replaced with something like

By approving this PR, ideally, you’d trigger a deployment (if you’re following GitOps processes).

IMPORTANT CAVEAT has no support for authenticating hooks, so unfortunately you can’t trust Webhooks, so I wouldn’t recommend this in production without some mechanism to prevent randoms on the internet triggering builds.


You could see this as an API for automating updating GitOps files, these are the fields you’d need to send.

It would certainly be possible to have an optional authentication header, and require API requests to send it, and block non-authenticated requests.

  "repository": "mynamespace/repository",
  "docker_url": "",
  "updated_tags": [