Open Source Repositories

With Reo.dev, you can now identify and monitor downloads of your open-source repositories through Docker and Helm. This short guide will walk you through how this works and how you can set it up.

How open-source Docker Images and Kubernetes Charts are downloaded

Developers who want to install your OSS package through a docker image will typically execute a command like this:

docker pull YourSoftware/version1

When this command is executed, the developer's system will download the docker image of your software hosted on Docker Hub.

Since Docker Hub is maintained by Docker, you will normally get only limited, aggregated analytics of pulls of your Docker image → such as aggregate counts of image pulls, origin countries of pull requests, aggregation of cloud services initiating a pull and domain classification (business, ISP, education) etc.

You will not get download-specific information, or the ability to de-anonymize docker pulls at user or organization level.

The use of Helm commands works in a similar manner → with the commands pulling Kubernetes charts from registries, and you as a publisher only getting aggregate statistics on download and usage.

This level of detail isn’t useful to GTM motions as it does not identify the actual company or developer initiating the pull.

Reo.dev Docker / Helm Redirection

Reo.dev uses a redirection system for docker and Helm commands helps you achieve this enhanced visibility. Here's how:

Reo creates a redirection layer that sits in front of your Open Source Software packages - whether they're on Docker, GitHub, GitLab or anywhere else.

reo.dev registry redirection flow

Users then replace the default pull command:

docker pull YourSoftware/version1
//OR
helm install yoursoftware-chart oci://registry-1.docker.io/charts/yoursoftware-chart

with a domain-specific command:

docker pull yourcompany.com/YourSoftware/version1
//OR
helm install yoursoftware-chart oci://yourcompany.com/charts/yoursoftware-chart

💡 Note: “yourcompany.com” serves as a proxy for actual package registry and is not a host of the package.

Your docker images will continue to be hosted at Docker Hub / Github or any other repository that you originally configured. Savvy users can always directly pull from the original package hub without anything breaking.

When a docker pull / helm install command is executed with the new domain-specific command, the request is redirected (307 redirect) on to the original registry for package download.

Reo.dev can map multiple packages to multiple registries. Each package will need a unique URL on “yourcompany.com” which maps to the correct package repository.

Example:

yoursoftware/version1 -> yourcompany.com/yoursoftware/version1
yoursoftware/version2 -> yourcompany.com/yoursoftware/version2
yoursoftware/betasoftware/version08 -> yourcompany.com/yoursoftware/betasoftware/version08

Since this redirection service and the URL (yourcompany.com/YourSoftware) is maintained by Reo.dev, you will now get far richer insights on the user downloading your software, just as if you were hosting it yourself.

You will get:

Information	Description
IP Level De-anonymization	De-anonymized developers who have downloaded your Docker image / Helm chart derived from their IP address
Company-level aggregation of Repository downloads	We aggregate Docker Pulls and Helm installs across an identified organization to create picture of adoption levels.

Final Flow Summary

Step	Description
1	User runs docker/helm with yourcompany.com
2	Request hits Docker/Helm endpoint of yourcompany.com
3	Request is proxied to reo.dev
4	reo.dev issues a 307 redirect to actual registry
5	Docker/Helm CLI downloads image/chart from registry

The redirection system ensures that while you gain enhanced visibility into who is downloading your packages, the actual downloads continue to happen directly from the original registries, maintaining performance and reliability.

Configuration Setup

Once you configure the Reo redirection system, your users will have the option to use the new URL to pull docker images. Update your documentation and Gtihub release notes to reflect the new URL.

💡 Note: Your docker images will continue to be hosted at Docker Hub / Github or any other repository that you originally configured. Savvy users can always directly pull from the original package hub without anything breaking.

Certificate Setup for HTTPS

To enable secure access, a TLS certificate for your custom domain (e.g., yourcompany.com) is required.

Issue a TLS Certificate

This certificate can be created yourself or by reo.dev for you. Get a TLS certificate from a trusted provider. Let's Encrypt offers free certificates, Amazon provides them through ACM if you use AWS, or you can purchase one from any established certificate company.

Update DNS & Install the Certificate

If reo.dev servers handles traffic or redirects for the domain (yourcompany.com), DNS records for that domain would need to point to reo.dev servers. The TLS certificate wold also need to be installed on reo.dev servers.

It's important to note that only the yourcompany.com domain requires the certificate - no other domains in the setup need certification. While the certificate can be issued and installed by either by you or reo.dev, it must be from a trusted source that client systems will recognize and accept.