Skip to content
Switch branches/tags
Go to file

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time

Caddy Ingress Controller

This is an Ingress Controller, which implements the ingress.Controller interface provided by

The implementation is fairly incomplete, in that it does not support any of the ingress annotations (yet!) but Caddy's straightforward configuration process should make them reasonably easy to implement for someone familiar with k8s networking.

Additionally, I have only done some limited testing of Caddy's automatic HTTPS features which utilize LetsEncrypt to automatically fetch and implement TLS certificates for hosts specified by Ingresses. I have managed to get it to work a few times, but not reliably enough to be able to say that this controller provides that feature at this time.


go get this repo, make sure you're signed into docker hub, then run

PREFIX={my-docker-username}/caddy-controller make push

A sample deployment.yaml has been included. Just replace the image name & email address with your own.


LetsEncrypt Email Address - Passed into the container via the ACME_EMAIL environment variable - currently set in the sample deployment.yaml.

LetsEncrypt Server - Currently set to Staging, which will provide test certs if successful. To change to production, comment out the -ca arg in pkg/cmd/controller/caddy.go. WARNING this controller is not yet ready for production use and changing this will almost certainly cause you to hit your LetsEncrypt rate limits, which will prevent you from getting new certs for your domain for a whole week!

Caddy Plugins - There's a comma-delimited list of plugins at rootfs/Dockerfile, just update that list before running make push

Development Contributions

Kubernetes has already taken care of the hard part - parsing out the Ingress definitions, organizing them, and automatically pinging the controller with updates when the definitions change. That means that further development of this controller mostly relies on understanding the ingress.Configuration struct received by the controller and mapping that out into a Caddyfile template.

The controller currently logs the updated config and Caddyfile template output to stdout for relatively easy debugging. The -log stdout argument is also being passed to the Caddy process so that its process logs will be printed as well.


Embedded Caddy

This controller was built primarily by following the nginx controller's example, but the differences between the two servers means that's not terribly ideal.

The current model has a controller process controlling a separate Caddy process, which is how the nginx controller works. One difference in implementation, however, is that Caddy doesn't need to restart the process entirely in order to load a new configuration - a live reload of the config is instead triggered by sending a USR1 signal to the Caddy process.

I think the model can be further improved by eliminating the secondary process altogether, embedding Caddy into the controller itself:


As defined by

Supported Name


Much of the code in this controller was copied from the nginx ingress controller, which is noted at the top of the copied files.


A Kubernetes ingress controller built on the Caddy web server (





No releases published


No packages published