Introduced in 0.28.0
Dokku provides integration with the Caddy proxy service by utilizing the Docker label-based integration implemented by Caddy.
caddy:report [<app>] [<flag>] # Displays a caddy report for one or more apps caddy:logs [--num num] [--tail] # Display caddy log output caddy:set <app> <property> (<value>) # Set or clear an caddy property for an app caddy:show-config <app> # Display caddy compose config caddy:start # Starts the caddy server caddy:stop # Stops the caddy server
caddy plugin integration requires the
docker-compose-plugin for Docker. See this document from the Docker documentation for more information on the installation process for the
As using multiple proxy plugins on a single Dokku installation can lead to issues routing requests to apps, doing so should be avoided. As the default proxy implementation is nginx, users are encouraged to stop the nginx service before switching to Caddy.
The Caddy plugin has specific rules for routing requests:
- Caddy integration is exposed via docker labels attached to containers. Changes in labels require either app deploys or rebuilds.
- While Caddy will respect labels associated with other containers, only
webcontainers have Caddy labels injected by the plugin.
https:443port mappings are supported.
- Caddy will automatically enable SSL if the letsencrypt email property is set. SSL will be disabled otherwise.
- If no
http:80mapping is found, the first
httpport mapping is used for http requests.
- If no
https:443mapping is found, the first
httpsport mapping is used for https requests.
- If no
httpsmapping is found, the container port from
http:80will be used for https requests.
- Requests are routed as soon as the container is running and passing healthchecks.
Switching to Caddy
To use the Caddy plugin, use the
proxy:set command for the app in question:
This will enable the docker label-based Caddy integration. All future deploys will inject the correct labels for Caddy to read and route requests to containers. Due to the docker label-based integration used by Caddy, a single deploy or rebuild will be required before requests will route successfully.
Any changes to domains or port mappings will also require either a deploy or rebuild.
Starting Caddy container
Caddy can be started via the
caddy:start command. This will start a Caddy container via the
docker compose up command.
Stopping the Caddy container
Caddy may be stopped via the
The Caddy container will be stopped and removed from the system. If the container is not running, this command will do nothing.
Showing the Caddy compose config
For debugging purposes, it may be useful to show the Caddy compose config. This can be achieved via the
Customizing the Caddy container image
While the default Caddy image is hardcoded, users may specify an alternative by setting the
image property with the
Checking the Caddy container's logs
It may be necessary to check the Caddy container's logs to ensure that Caddy is operating as expected. This can be performed with the
This command also supports the following modifiers:
You can use these modifiers as follows:
The above command will show logs continually from the vector container, with an initial history of 10 log lines
Changing the Caddy log level
Caddy log output is set to
ERROR by default. It may be changed by setting the
log-level property with the
After modifying, the Caddy container will need to be restarted.
The caddy plugin only supports automatic ssl certificates from it's letsencrypt integration. Managed certificates provided by the
certs plugin are ignored.
Enabling letsencrypt integration
By default, letsencrypt is disabled and https port mappings are ignored. To enable, set the
letsencrypt-email property with the
After enabling, the Caddy container will need to be restarted and apps will need to be rebuilt. All http requests will then be redirected to https.
Customizing the letsencrypt server
The letsencrypt integration is set to the production letsencrypt server by default. To change this, set the
letsencrypt-server property with the
After enabling, the Caddy container will need to be restarted and apps will need to be rebuilt to retrieve certificates from the new server.
Using Caddy's Internal TLS server
To switch to Caddy's internal TLS server for certificate provisioning, set the
tls-internal property. This can only be set on a per-app basis.
Displaying Caddy reports for an app
You can get a report about the app's Caddy config using the
=====> node-js-app caddy information Caddy image: lucaslorentz/caddy-docker-proxy:2.7 Caddy letsencrypt email: Caddy letsencrypt server: Caddy log level: ERROR Caddy polling interval: 5s Caddy tls internal: false =====> python-app caddy information Caddy image: lucaslorentz/caddy-docker-proxy:2.7 Caddy letsencrypt email: Caddy letsencrypt server: Caddy log level: ERROR Caddy polling interval: 5s Caddy tls internal: false =====> ruby-app caddy information Caddy image: lucaslorentz/caddy-docker-proxy:2.7 Caddy letsencrypt email: Caddy letsencrypt server: Caddy log level: ERROR Caddy polling interval: 5s Caddy tls internal: false
You can run the command for a specific app also.
You can pass flags which will output only the value of the specific information you want. For example: