For the complete documentation index, see llms.txt. This page is also available as Markdown.

Docker & Helm

With Reo, you can identify and monitor Docker and Helm downloads of your open-source repositories. This guide covers how container images and Helm charts are routed through Reo, and what you need to set up.

Substitute your own domain for yourcompany.com throughout.


How it works

  • Your images and charts are published on a domain you own: registry.yourcompany.com

    • That hostname is what already sits in your users' Docker files, CI pipelines, and install docs, regardless of which registry actually stores them

  • Turning Reo.dev on means repointing that hostname with a CNAME

  • Reo records the pull, then returns a 307 to the registry that actually stores the artifact - nothing your users type changes

registry.yourcompany.com  ->  yourcompany.docker.reo.dev  ->  307  ->  registry-1.docker.io
charts.yourcompany.com    ->  yourcompany.helm.reo.dev    ->  307  ->  registry-1.docker.io

      your domain              Reo.dev records the pull             your registry serves it
lightbulb

Prerequisite: a domain published in front of your registry

  • Set it up, put it in your docs as the pull URL, and point it at Reo.dev

  • After that, the URL never needs to change again

docker run -p <HOST_PORT>:<CONTAINER_PORT> <REGISTRY>/<NAMESPACE>/<IMAGE>:<TAG>

  • The image registry needs to point to the Reo-enabled registry/image for the tracking events to be captured

Here's how this should look:

Before: docker run -p <HOST_PORT>:<CONTAINER_PORT> <NAMESPACE>/<IMAGE>:<TAG> After: docker run -p <HOST_PORT>:<CONTAINER_PORT> <REGISTRY_URL>/<NAMESPACE>/<IMAGE>:<TAG>

The Docker and Helm CLIs follow 307 redirects natively. No client-side configuration is required.

The redirect is served by CloudFront with Lambda@Edge, so it is answered at the edge location nearest to the developer or CI runner that made the request. Pulls from any region cost a few milliseconds at the edge rather than a round trip to a single origin.

Nothing is re-hosted. Images and charts continue to be served from your existing registry. Reo holds no copy of them.


What stays the same

  • The pull URL: Your users keep using the hostname they already have. No re-publishing, no migration notice, no change to anything already pinned.

  • Where your artifacts live: Images and charts stay in Docker Hub, GHCR, ECR, or wherever they are today.

  • Direct pulls: Pulling from the original registry URL still works. Nothing is cut off, and you can migrate at your own pace.

  • Digests and signatures: The redirect changes the transport, not the content, so digests match and Cosign / Notation verification is unaffected.

  • Pull performance: Layers stream from the origin registry. Reo.dev is never in the data path.


Request flow

Step
What happens

1

Developer runs docker pull or helm install against your hostname

2

registry.yourcompany.com resolves to yourcompany.docker.reo.dev via CNAME

3

Request reaches the Docker / Helm endpoint

4

A 307 redirect is returned, pointing at your origin registry

5

The CLI pulls the image or chart directly from that registry


What you need to do

  1. Choose the hostnames you want to publish: A subdomain per artifact type is typical (registry.yourcompany.com for images, charts.yourcompany.com for charts), though a single hostname can serve both. If you don't have them yet, create and publish them before going further.

  2. Add the routing CNAME records: Reo provisions a dedicated endpoint for your account and gives you the exact target values.

  1. Add the certificate validation CNAME records: Reo issues and installs the TLS certificates for these hostnames (there is nothing to purchase, upload, or renew), but issuance requires domain validation. Reo provides the exact record values; add them alongside the routing records and leave them in place, as the certificates re-validate on every renewal.

  2. Update your published pull commands. README files, docs site, release notes, and quickstart snippets should point at the new hostname. This step is what actually drives adoption.

That's the whole change. Your published pull commands stay exactly as they are.


Last updated

Was this helpful?