Split private location container images into separate runtime versions
I would love to see the container only have the latest runtime, and then tag the container with the runtime version.
Right now the version numbers seem decoupled from the runtime - the latest is 6.3.2, but it would be awesome to have them tagged like this:
checkly/agent:2025.04-6.3.2
and
checkly/agent:2024.09-6.3.2
For two reasons, I'd love to have a smaller image, and also because it minimizes the security footprint. Our scans of the images turn up a number of vulnerabilities especially with the older runtime, so each update requires us getting it approved with our security team.
For at least some subset of customers, we’re not running both runtimes at the same time, so having the extra runtime in our environment is counter-productive.
Log in to comment and vote
Comments3
Hervé Labas
Jul 27
Hi,
We’ve worked out our release automation to significantly improve images build out and keep up with vulnerabilities.
We released a v8 that only contains the latest image, and have separate migration images for folks who want to transition from a runtime to another.
This is not yet matching your aspiration, but that latest image is limiting the vulnerability exposure:
https://www.checklyhq.com/docs/platform/private-locations/change-log/#v8-0-0
In practice your security team should approve the new image + the migration one (which is de facto the older runtime + the latest one already asked for approval, so should be ideally a no-op).
Is it of any help?
Thank you
John Dyer
Jul 27
Hey Hervé,
I saw the 8.0.0 note when it came out “Latest agent image with runtime 2026.04 only.” and that was a big step forward, but I recall there being a lot of dependencies that still needed work back then. We can rescan and take a look
Thanks for reaching out, 8.0.0 really addressed 80% of what I was looking for here.
John
Hervé Labas
Jul 29
Good, this hopefully improves things a little.
We’ll be soon working on a new image to make further dependencies updates and will follow the same approach: one image with a single runtime, and temporary images meant to ease the migration from the current/old to the new one