Uploaded August 2025 | Updated September 2026, 2 weeks ago
Together with Matias Pan & Marcos Nils, our primary goal was to establish a container registry operating through CloudFront, effectively positioning CloudFront as a frontend for ghcr.io.
While ghcr.io provides a generous free tier that served us well for years, the existing analytics on ghcr.io offer limited insights, latency is sometimes poor, and unavailability hits hard. A custom domain allows us to gather more granular data, makes requests consistently faster & more reliable anywhere in the world, and we have the option of switching container registries without disrupting users.
A significant challenge in this project was understanding the HTTPS traffic between the user's machine and the CloudFront endpoint. To do this without the complexity of a man-in-the-middle proxy, we used eCapture, a powerful tool that leverages eBPF (Extended Berkeley Packet Filter) to capture SSL/TLS traffic in plaintext. This allowed us to inspect the requests and responses, understand the authentication flow, and identify which requests to cache.
By using eCapture, we demonstrate that the new setup works as expected. We show how the Docker CLI interacts with the CloudFront endpoint, how the token is fetched, and how the manifest and blobs are pulled. We also demonstrate that the caching is working correctly, with subsequent requests for the same image being served from the CloudFront cache, resulting in a significant performance improvement - it's 100% faster.
We plan to continue optimizing this setup including:
- Caching the token: To limit the impact of ghcr.io service disruption
- Fine-tuning the caching policies: To further improve performance and reduce costs
- Origin shield: To reduce the load on ghcr.io
There is more to this:
- Sign-up at ๐บ makeitwork.tv for the full length content
- Tune into ๐ง https://makeitwork.fm for the podcast
- Join ๐ชฉ makeitwork.club for regular members-only discussions
00:00 Intro
00:36 What are we trying to achieve?
01:44 Why custom domain for ghcr.io?
03:34 registry-redirect
05:48 vector.dev
07:45 ecapture
14:44 ecapture new image from registry.dagger.io
21:56 Does it work?
29:47 How can we improve on this?
31:56 Is it faster than ghcr.io?
36:59 How to set this up
42:58 Follow-up optimisations
Together with Matias Pan & Marcos Nils, our primary goal was to establish a container registry operating through CloudFront, effectively positioning CloudFront as a frontend for ghcr.io.
While ghcr.io provides a generous free tier that served us well for years, the existing analytics on ghcr.io offer limited insights, latency is sometimes poor, and unavailability hits hard. A custom domain allows us to gather more granular data, makes requests consistently faster & more reliable anywhere in the world, and we have the option of switching container registries without disrupting users.
A significant challenge in this project was understanding the HTTPS traffic between the user's machine and the CloudFront endpoint. To do this without the complexity of a man-in-the-middle proxy, we used eCapture, a powerful tool that leverages eBPF (Extended Berkeley Packet Filter) to capture SSL/TLS traffic in plaintext. This allowed us to inspect the requests and responses, understand the authentication flow, and identify which requests to cache.
By using eCapture, we demonstrate that the new setup works as expected. We show how the Docker CLI interacts with the CloudFront endpoint, how the token is fetched, and how the manifest and blobs are pulled. We also demonstrate that the caching is working correctly, with subsequent requests for the same image being served from the CloudFront cache, resulting in a significant performance improvement - it's 100% faster.
We plan to continue optimizing this setup including:
- Caching the token: To limit the impact of ghcr.io service disruption
- Fine-tuning the caching policies: To further improve performance and reduce costs
- Origin shield: To reduce the load on ghcr.io
There is more to this:
- Sign-up at ๐บ makeitwork.tv for the full length content
- Tune into ๐ง https://makeitwork.fm for the podcast
- Join ๐ชฉ makeitwork.club for regular members-only discussions
00:00 Intro
00:36 What are we trying to achieve?
01:44 Why custom domain for ghcr.io?
03:34 registry-redirect
05:48 vector.dev
07:45 ecapture
14:44 ecapture new image from registry.dagger.io
21:56 Does it work?
29:47 How can we improve on this?
31:56 Is it faster than ghcr.io?
36:59 How to set this up
42:58 Follow-up optimisations










