
How to use your own private local registry with Docker
How to use your own private local registry with Docker êŽë š

One of the things that makes Docker so useful is how easy it is to pull ready-to-use images from a central location, Dockerâs CentralRegistry. It is just as easy to push your own image (or collection of tagged images as arepository) to the same publicregistry so that everyone can benefit from your newly Dockerized service.
But sometimes you canât share your repository with the world because it contains proprietary code or confidential information. Today we are introducing an easy way to share repositories on your own registry so that you can control access to them and still share them among multiple Docker daemons. You can decide if your registry is public or private.
Youâll need the latest version of Docker (>=0.5.0) to use this new feature, and you must run this version as both the daemon and the client. Youâll also need the Docker registry code (dotcloud/docker-registry
).
Using Push and Pull
The default way of pushing and pulling repositories from the Central Registry has not changed:
# Pull the ubuntu base image:
docker pull ubuntu
# Push the Hipache image (if you're samalba!)
docker push samalba/hipache
Implicitly that push
and pull
each access the Central Registry at index.docker.io
, so nothing has changed with the default behavior and all the examples still work.
Now the new feature!
To push to or pull from your own registry, you just need to add the registryâs location to the repository name. It will look like my.registry.address:port/repositoryname
.
Letâs say I want to push the repository âubuntuâ to my local registry, which runs on my local machine, on the port 5000:
# First, make sure you have the "ubuntu" repository:
docker pull ubuntu
# Then, find the image id that corresponds to the ubuntu repository
docker images | grep ubuntu | grep latest
ubuntu latest 8dbd9e392a96 12 weeks ago 263 MB (virtual 263 MB)
# Almost there!
# Tag to create a repository with the full registry location.
# The location becomes a permanent part of the repository name.
docker tag 8dbd9e392a96 localhost.localdomain:5000/ubuntu
# Finally, push the new repository to its home location.
docker push localhost.localdomain:5000/ubuntu
Obviously, the push will fail if no registry server answer locally on the port 5000. Weâll briefly show how to start your own registry server at the end of this blog post.
Itâs important to note that weâre using a domain containing a â.â here, i.e. localhost.domain
. Docker looks for either a â.â (domain separator) or â:â (port separator) to learn that the first part of the repository name is a location and not a user name. If you just had localhost
without either .localdomain
or :5000
(either one would do) then Docker would believe that localhost
is a username, as in localhost/ubuntu
or samalba/hipache
. It would then try to push to the default Central Registry. Having a dot or colon in the first part tells Docker that this name contains a hostname and that it should push to your specified location instead.
Install your Registry (on your server or locally)
Docker-Registry is a simple Python app, installing it is straight-forward (dotcloud/docker-registry
):
git clone https://github.com/dotcloud/docker-registry.git
cd docker-registry
cp config_sample.yml config.yml
pip install -r requirements.txt
gunicorn --access-logfile -\
--log-level debug \
--debug \
-b 0.0.0.0:5000 \
-w 1 wsgi:application
Your Registry is now running on localhost (port 5000) in a development flavor and using local storage. Obviously, in a production environment, you might want to run the Registry on port 443 (or 80 on a local network) and make it accessible on a hostname like âregistry.domain.tldâ, and point it to use S3 or other storage.
About Sam Alba

As dotCloudâs first engineering hire, Sam was part of the tiny team that shipped our first private beta in 2010. Since then, he has been instrumental in scaling the platform to tens of millions of unique visitors for tens of thousands of developers across the world, leaving his mark on every major feature and component along the way. Today, as dotCloudâs first director of engineering, he manages our fast-growing engineering team, which is another way to say he sits in meetings so that other engineers donât have to. When not sitting in a meeting, he maintains several popular open-source projects, including Hipache and Cirruxcache and other projects also ending in â-acheâ. In a previous life, Sam supported Fortune 500s at Akamai, built the web infrastructure at several startups, and wrote software for self-driving cars in a research lab at INRIA.
Connect with Sam on Twitter! @sam_alba
