Where my Container Images live (and why)

1. Why it’s important to choose where to store your Images

Once you’ve built your container image, you must decide where to store it. Images are kept in Container Registries, and there are many different options to choose from. Picking one over another carries various implications. Which container registry is the best?

One factor to keep in mind is the cost. Some Registries let you store images for free up to the first N GB of disk space. Other Registries charge from the very first megabyte of storage. There are also limits on how many distinct images you can host. Some Registries have different pricing depending on whether an image is public or private. Monthly data transfer costs also come into play, both for uploading (push) and downloading (pull) images.

The Registry location is another key factor since its geographic proximity affects speed and latency when transferring images to and from it.

In short, there are several variables to consider when deciding the best place to store your container images. My goal is that, by the end of this article, you’ll be able to choose the option that makes the most sense for you, and you’ll also know my preferred solution.

2. What I used to do

The first Registry that usually comes to mind is Docker Hub. Perhaps out of inertia, due to unfamiliarity with other alternatives, I’ve always stored my images on Docker Hub. It’s easy to use, it’s the “official” Docker Container Registry (created by Docker, Inc.), and it’s the most famous service of its kind. Plus, it hosts the most widely used public images, like Memcached, Nginx, Alpine, Ubuntu, and Redis, among others.

Docker Hub offers a simple interface and a free plan that lets you have one private repository at no cost and unlimited public repositories.

However, over time I’ve run into certain limitations on Docker Hub that have led me to prefer other alternatives. Recently, Docker Hub limited pulls for unauthenticated users to 100 pulls every 6 hours per IPv4 address (or per /64 IPv6 prefix), and to 200 pulls per hour for authenticated users on the Personal plan.

So, to choose the most suitable Registry for my use case, I asked myself which features I needed it to have.

3. What I need from a Container Registry

The images stored in a Registry will eventually be deployed to a server running on a cloud provider. Therefore, it is important that the following requirements be met:

Bandwidth/latency: images must be deployed quickly to the server. If this isn’t achieved, the deployment process will take longer, which is undesirable.
High availability/fault tolerance: the storage location for the images must be reliable and always available. If the service goes down, we won’t be able to perform a new deployment of our application.
Rate limiting: it shouldn’t enforce very low limits, as that could interrupt the image upload/download process.
Cost: although cost is important, it is not the most critical factor. If a Registry meets the other requirements, cost becomes a secondary consideration (unless it is significantly more expensive than other alternatives).
Garbage collection: some registries do not immediately free up space after an image is deleted; instead, you must invoke a garbage collection process to fully release the space. This adds an extra step to ensure storage costs don’t skyrocket.

4. The options I considered

First, it’s important to distinguish between self‑hosted Registries and managed Registries.

A self‑hosted Registry means installing, setting up, and maintaining the Registry yourself. However, since the Registry is a critical component, I decided to rule out this option entirely and opt for a managed solution.

Among the managed options there are standalone Registry services and cloud‑provider Registries.

Some examples of managed Registries:

These kinds of Registries generally work well; however, I believe they are not the best option because, at first glance, we don’t know in which geographic region the images will be stored—and therefore what impact that will have on bandwidth and latency when interacting with the Registry.

5. Where my Container Images live now

In order to optimize bandwidth and latency, I prefer to use the Registry provided directly by the cloud provider where the servers associated with the application to be deployed reside.

Some examples of cloud‑provider Registries:

I currently use DigitalOcean as my primary provider, so I store my images in the Container Registry it offers.

This is exactly what Deckrun does automatically: it creates a Container Registry in the cloud provider of your choice for deploying your applications and places it in the region closest to your Cluster nodes to provide all the advantages I mentioned above.

6. Final thoughts and recommendations

It’s important to choose wisely where to store our images.
This choice impacts security, performance, costs, and the development experience.
Geographic location (provider, region, zone) is key to optimizing bandwidth and latency.
A cloud provider’s Registry is generally the best option.
Ideally, we shouldn’t have to worry about the garbage collection process.
Storage and transfer costs must be kept under control so they don’t spiral out of hand.