What would you want from a Certbot Docker image?

There has been some demand for a Certbot Docker image. While we currently have one hosted on quay.io, we feel that this file can be greatly improved. To know what direction to take the Certbot Dockerfile(s), we’d like to know how you plan to use it.

The big hurdle with running Certbot in Docker is many of Certbot’s plugins cannot be easily used. To use webroot, every webroot has to be mounted in the container running Certbot. To use standalone, incoming connections on port 80/443 in the host system need to be mapped into the Certbot container.

Using an installer plugin to automatically install the certificate that Certbot obtains is extremely difficult, unless the server you want to install the certificate to is also running in the same Docker container. This is because, at least in the case of the official installer plugins such as Apache and Nginx, Certbot needs access to the executables for your web server in order to restart/reload your web server (and they need to work).

In short, what’s your use case for running Certbot in Docker? Please tell us what you’d like to see from a Certbot Docker image and how you plan to use it.

Here is my use case with Nginx:

Start Nginx:

docker run -d --name proxy \
           --volume=/home/core/configuration/nginx.conf:/etc/nginx/nginx.conf:ro \
           --volume=letsencrypt-data:/etc/letsencrypt:ro \
           -p 80:80 -p 443:443 \

Then I run one of the following commands within a cron job once per day:

Run with a configuration file (/host/path/to/cli.ini):

docker run -it \
           --volume=letsencrypt-data:/etc/letsencrypt \
           --volume=/host/path/to/cli.ini:/etc/letsencrypt/cli.ini:ro \

Run with inline configuration:

docker run -it \
           --volume=letsencrypt-data:/etc/letsencrypt \
           --env='DOMAINS=example.com,www.example.com' \
           --env='EMAIL=contact@example.com' \

I start the container from my image but this image inherits from the official one on quay.io. Maybe this logic could be directly imported to the official image?

Please find more details here


Hi bmw

A docker image is a great idea.

I was thinking about some of the limitations of certbot currently and one of them is a lack of centralized command strucutre whereby certbot or other clients are essentially the servers and connect to “slaves” to configure.

This could be done via:
Certbot “client” to be installed on each server
Utilizing current devop tools such as puppet,ansible etc

This would make a docker image useful as lots of people are deploying docker to get either compartmentalization or efficiency from their server.

I’ve recently started using Docker. So far I have migrated our DNS and web servers to Docker containers at hyper.io (a Docker hosting service). The web server container contains only the Caddy web server which automatically sets up Lets Encrypt certificates out of the box.

In the long term I plan to migrate all the services I operate (HTTP, SMTP, IMAP, etc) to separate Docker containers for each service. However due to the shortage of IPv4 addresses I intend to host all the containers on a single VPS so they will share a single IPv4 address.

Aside: I would like to make the point here that if I was able to give each of my container an IPv6 address (assuming IPv4 has finally died) then I would simply just configure each container to get a Let’s Encrypt certificate using whatever method works (e.g. Caddy for HTTP, and certbot for everything else).

So back to the current situation where all containers are attached to the same IPv4 address…

Currently I can’t seem to come up with a sensible and well documented approach for automatic certificate renewal that will work across all services. Caddy only really works well if it is the only service on a particular IP address. So I’m currently looking at possibly building something around certbot and integrating it with my HTTP, SMTP, IMAP, etc servers.

I suspect that it may be more fitting with the Docker philosophy to have a separate container that just runs the certificate renewal process (i.e. certbot). Then there needs to be a standardized process for the service containers (e.g. HTTP, SMTP, IMAP, etc) to pull the the most current certificate periodically.

It would be nicer for the certbot container to push it to the services when the certificate is renewed but that’s probably another whole can of worms!

I don’t have a strong opinion on how the certbot container should interface with other containers, except to say that recommended approach should be provided by the maintainer. That approach, in whatever form it takes, should be well documented, also by the maintainer, with high quality examples of real world usage.

Thanks! :slight_smile:

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.