Request icon
Script icon
Docker icon
If icon
Schedule icon

dockerDash

Check a repo's Dockerfile against Docker Hub on a schedule and open a pull request bumping outdated image tags. No duplicates, no noise.

Categories
CoreInfrastructure

Pinned Docker image tags go stale quietly. Nobody checks every FROM line against Docker Hub each week, so projects keep building on old base images until something breaks. This blueprint turns a scheduled Docker Hub check into an automatic bump PR: it reads the Dockerfile, asks Docker Hub for the latest tag of each image, and opens one pull request with the updates.

How it works

  1. fetch_dockerfile (io.kestra.plugin.core.http.Request) asks the GitHub API for the Dockerfile on the base branch. GitHub returns the file base64-encoded.
  2. get_base_sha (io.kestra.plugin.core.http.Request) asks the GitHub API for the latest commit on the base branch. The new bump branch starts from this commit.
  3. list_open_prs (io.kestra.plugin.core.http.Request) asks the GitHub API for the repo's open pull requests, so the flow never opens a duplicate bump PR.
  4. find_outdated (io.kestra.plugin.scripts.python.Script) decodes the file, goes line by line through the FROM instructions, asks Docker Hub for each image's tags, and keeps only the outdated numeric tags that do not already have an open bump PR. Tags like latest or alpine, digest pins, and images from other registries are skipped because there is no version to compare. It also builds the updated Dockerfile and the new branch name.
  5. process_updates (io.kestra.plugin.core.flow.If) runs only when something is outdated. Inside it, create_branch makes the bump branch, update_file writes the new Dockerfile to it, and open_pr opens the pull request.

What you get

  • A scheduled Docker Hub check for every numeric image tag in the Dockerfile.
  • One pull request per run with all the outdated tags bumped, never two PRs for the same image.
  • A quiet run when everything is already current: no branches, no PRs, no noise.

Who it's for

  • Teams whose Dockerfiles only get their base images updated when someone remembers.
  • Maintainers who want image updates as reviewable PRs instead of surprise rebuilds on old bases.
  • Anyone running containers in production who would rather bump deliberately than discover staleness during an incident.

Why orchestrate this with Kestra

There is no Dependabot for Docker Hub tags that you control end to end. Kestra keeps the whole thing in one visible flow: the schedule, the Docker Hub tag check, the duplicate-PR guard, and the branch and PR creation are all one auditable execution history, and every step is editable. You can change which tags count as versioned, add an ignore list, or change the schedule without waiting on a third-party bot.

Prerequisites

  • A GitHub repo with a Dockerfile using numeric image tags.
  • A Kestra instance with Docker, because the tag check runs in a Python container.

Secrets

  • GITHUB_TOKEN: GitHub personal access token with repo scope. The flow creates branches, writes files, and opens pull requests. In Kestra OSS, secrets are supplied as environment variables prefixed SECRET_, base64-encoded, and read back with {{ secret('NAME') }}, for example SECRET_GITHUB_TOKEN=$(echo -n '<token>' | base64).

Quick start

  1. Save your GitHub token as the GITHUB_TOKEN secret (base64-encoded, see above).
  2. Import the flow and hit Execute. Type the repo owner and repo name when it asks; the file path and branch already have defaults.
  3. Check the execution: if anything was outdated, a bump PR is now open on the repo.
  4. The Wednesday schedule takes care of the rest.

How to extend

  • Point dockerfile_path at a Dockerfile in a subdirectory.
  • Keep the distro suffix when bumping (for example 1.28-alpine to 1.31-alpine) by matching on the current tag's suffix in the Python step.
  • Add an ignore_images input and skip those images in the Python step.

Inputs

  • repo_owner: who owns the repo.
  • repo_name: the repo name.
  • dockerfile_path: where the Dockerfile lives (defaults to Dockerfile).
  • base_branch: the branch the bump branch starts from (defaults to main).

Links

Pitfalls

  • Docker Hub returns at most 100 tags per request, so for images with very long tag lists the newest tag might sit beyond the first page.
  • If a maintainer closes a bump PR without merging, the next run will propose it again, because closing is not the same as merging.
Share this Blueprint
See How

New to Kestra?

Use blueprints to kickstart your first workflows.