You can add plugins to Caddy directly on the Download page, or you can use xcaddy to build a binary yourself.
The official Docker image also has instructions on its README explaining how to get a custom build into a Docker container (using xcaddy); you’re looking for the “Adding custom Caddy modules” heading.
Okay, there’s a whole lot of different problems to try and unravel here.
Just to clarify, you’re not downloading individual plugins, you’re downloading an entire compiled binary with the plugins you selected included. As for what you do with it, you can just replace your existing binary (the one that has no plugins). Drop-in replacement. Reboot service and you should be good to go.
We might be able to help you with that if you explain what’s happening. What are you trying to achieve with it, what specifically did you try (e.g. what exact commands did you use), and what result did you get (e.g. just copy the outputs - we need to know the exact error codes etc.).
This depends wildly on the specifics of your requirements. But if you’re doing stuff pretty normally, your compose file probably just needs to use the Caddy binary as its entry point, with a command that points it to a mounted Caddyfile, a volume to preserve the TLS assets, and port mappings for whatever you intend Caddy to serve on. Docker help is beyond the scope of these forums, but a number of us here do use Docker ourselves, so we might be able to help with your questions along these lines.
You only need to copy it in place of the existing binary (wherever that is).
Easiest way is not to use a command, but to browse to https://caddyserver.com/download, select the plugins you want, and use the download button link.
Where?
If you have some evidence to suggest xcaddy is broken somehow, or the README is incorrect, we would love to see it. Generally we want to make sure the program works exactly as advertised; as soon as you can tell us what went wrong, we can start looking into it.
if you are not using docker and want to have the system configured to run caddy;
yes download the caddy binary with the plugin(s) you want for the architecture you are on from Download Caddy
you can replace /usr/bin/caddy or define with update-alternatives to link /usr/bin/caddy to your target release wherever you are staging it on the filesystem
Here is the text - quoted in full - from https://hub.docker.com/_/caddy, under the “Adding custom Caddy modules” heading, which has been linked to a few times above.
You can use the :builder image as a short-cut to building a new Caddy binary:
FROM caddy:<version>-builder AS builder
RUN xcaddy build \
--with github.com/caddyserver/nginx-adapter \
--with github.com/hairyhenderson/caddy-teapot-module@v0.0.3-0
FROM caddy:<version>
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
Note the second FROM instruction - this produces a much smaller image by simply overlaying the newly-built binary on top of the the regular caddy image.
The xcaddy tool is used to build a new Caddy entrypoint, with the provided modules. You can specify just a module name, or a name with a version (separated by @). You can also specify a specific version (can be a version tag or commit hash) of Caddy to build from. Read more about xcaddy usage.
:latest-builder doesn’t exist. You can use either :builder, or :2.4.6-builder. Refer to the top of the page on Docker to see the full list of valid tags.
Generally, it’s best to pin to a specific version, so that you explicitly upgrade on your own time. There’s no guarantee that changes in Caddy won’t be breaking – we may make a change to some configuration option (we try to avoid them, but it can happen that we need to do it for important reasons). Using latest is dangerous for that reason.
You can simplify this to just:
build: /opt/caddy
Basically, it just needs to be a path to the directory that contains your Dockerfile. If your docker-compose.yml is right beside your Dockerfile, you could simplify it even more to just this:
build: .
You don’t need this line, because the default container name will be the name of the service, i.e. caddy, prefixed with the project name (which by default is the directory in which you’re running your docker-compose commands, if that’s /opt/caddy then the project name will be caddy) and suffixed by a number (in case you were to run multiple replicas – you aren’t though). So your container name would be caddy_caddy_1. Which is fine.
Yep. First time you run docker-compose up -d, it’ll build it. Next time you run it, it’ll already have been built, so it wouldn’t need to do it again. If you need to rebuild (upgrading versions, changing plugins), then run docker-compose build, then run it again with docker-compose up -d.