A reverse proxy for the Docker Registry 2.0, based on silintl/apache2.

It implementing basic password authentication and is tweaked so as to induce correct/useful behavior in the daemons which pull through it.

SSL is configured but optional.

All secrets are passed in at run time, via environmental variables.

Runtime Configuration

There is one mandatory environmental variable:


REGISTRY_HOST is the reverse proxy destination. If you are also running the registry in another container, and have linked to it properly, then you can just specify the short hostname that linking creates by setting this container's /etc/hosts file, like so:


If you wish to enable SSL, set the following:


Furthermore, the image expects the following files to be located in /data on the container's filesystem:

  • htpasswd: AuthUserFile password database, for authentication

And if SSL is enabled:

  • server.crt: the proxy's SSL public certificate
  • server.key: the proxy's SSL private key

None of these files are included in the images, so you must ensure that they are added at container runtime, either by mounting a volume, or using the functionality of the included script, which is already set as the ENTRYPOINT.

This script is a wrapper, run before the CMD. It can create files in the container by extracting data from other environmental variables, and/or pulling and unpacking tar archives from S3.

Operation is determined by the setting the following environmental variables. If neither are set, the script merely just runs the main CMD.


The value of EXPAND_FILES must be a space-delimited list of key-value pairs, each separated by an equals sign. For each pair, the key is the name of a referenced environmental variable, and the value is the path to a new file, whose contents will be the current value of the referenced variable. All parent directories in the path will be created if they do not exist, and if the referenced environmental variable is not set, that particular key-value pair will be ignored. You can also append [mode], [mode|owner], or [|owner] to the path to set the numerical file permissions, and/or the file owner. Since newlines are not allowed in environmental variables, the script will replace any ascii SUB character (\032 or \x1a) in the the value of the referenced environmental variable with a newline in the created file.

So, as an example, suppose the following are set for the container:

EXPAND_FILES= ISSUE=/etc/issue SPECIFIC=/home/foo/.bashrc[0644|foo] FORGOT=/data/my_file

ISSUE=Linux, running in Docker!

The wrapper script will then, when the container is started, overwrite /etc/issue with "Linux, runnning in Docker!" (adding a newline at the end), create /home/foo/.bashrc with contents "cd ~" (no newline at the end), and do nothing for /data/my_file, since FORGOT was not set.

The value of EXPAND_S3_TARS must be a space-delimited list of key-value pairs, each separated by a pipe (|). The key is the location of a tar archive in S3, in the format bucket/path. The value is is the directory in which the archive should be extracted. This target directory will be created if it does not already exist.

If set, EXPAND_S3_TARS requires two other environmental variables to be set in order to work. They are:


So, for example, suppose the following are set for the container:

EXPAND_S3_TARS= DXCmEdg4gb/data.tar|/data yBO8IJ/homes/foo/special.tar|/home/foo/my_dir


The wrapper script will use the provided key and secret to grab s3://DXCmEdg4gb/data.tar and s3://yBO8IJ/homes/foo/special.tar, unpacking them into /data and /home/foo/my_dir, respectively.

You can pass in these environmental variables using docker's --env-file switch; see ENV-FILE.example for an example of what this file might look like.

Generating the HTPASSWORD file

The OpenSSL CLI can be used to calculate password hashes, like so:

openssl passwd -apr1