> For the complete documentation index, see [llms.txt](https://docs.reo.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reo.dev/integrations/input-sources/developer-insights/docker-and-helm.md).

# 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 <mark style="color:red;">`yourcompany.com`</mark> throughout.

***

### **How it works**

* Your images and charts are published on a domain you own: <mark style="color:red;">`registry.yourcompany.com`</mark>
  * 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 <mark style="color:red;">`307`</mark> 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
```

{% hint style="info" icon="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

<mark style="color:red;">`docker run -p <HOST_PORT>:<CONTAINER_PORT> <REGISTRY>/<NAMESPACE>/<IMAGE>:<TAG>`</mark>&#x20;

* 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:***&#x20;

Before: <mark style="color:red;">`docker run -p <HOST_PORT>:<CONTAINER_PORT> <NAMESPACE>/<IMAGE>:<TAG>`</mark>\
After: <mark style="color:red;">`docker run -p <HOST_PORT>:<CONTAINER_PORT> <REGISTRY_URL>/<NAMESPACE>/<IMAGE>:<TAG>`</mark>
{% endhint %}

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.

<figure><img src="https://2705882080-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fx46P5sAHxDG7PqOdVLxI%2Fuploads%2FsFLjnTl8Zi1fUqFFvy7u%2Fimage.png?alt=media&amp;token=058b03f6-fe08-4a4b-b177-c739167d40cd" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Nothing is re-hosted. Images and charts continue to be served from your existing registry. Reo holds no copy of them.
{% endhint %}

***

### 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.&#x20;
* **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 <a href="#how-open-source-docker-images-and-kubernetes-charts-are-downloaded" id="how-open-source-docker-images-and-kubernetes-charts-are-downloaded"></a>

<table><thead><tr><th width="79.15234375">Step</th><th>What happens</th></tr></thead><tbody><tr><td>1</td><td>Developer runs <mark style="color:red;"><code>docker pull</code></mark> or <mark style="color:red;"><code>helm install</code></mark> against your hostname</td></tr><tr><td>2</td><td><mark style="color:red;"><code>registry.yourcompany.com</code></mark> resolves to <mark style="color:red;"><code>yourcompany.docker.reo.dev</code></mark> via CNAME</td></tr><tr><td>3</td><td>Request reaches the Docker / Helm endpoint</td></tr><tr><td>4</td><td>A 307 redirect is returned, pointing at your origin registry</td></tr><tr><td>5</td><td>The CLI pulls the image or chart directly from that registry</td></tr></tbody></table>

***

### What you need to do  <a href="#how-open-source-docker-images-and-kubernetes-charts-are-downloaded" id="how-open-source-docker-images-and-kubernetes-charts-are-downloaded"></a>

1. **Choose the hostnames you want to publish:** A subdomain per artifact type is typical (<mark style="color:red;">`registry.yourcompany.com`</mark> for images, <mark style="color:red;">`charts.yourcompany.com`</mark> 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.

```
registry.yourcompany.com.   CNAME   yourcompany.docker.reo.dev.
charts.yourcompany.com.     CNAME   yourcompany.helm.reo.dev.
```

3. **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.
4. 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.&#x20;

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

***


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.reo.dev/integrations/input-sources/developer-insights/docker-and-helm.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.