Currently supported build(s): v0.20.1-alpine, v0.20.1-debian "Cowberry" (rolling release), built upon v2.8.4
(by mistake I pushed 0.19.4 as 0.19.3 so that's amazing... next release going to be 0.19.5 due to it)
This repository contains ready-to-use multi-platform images for Caddy built using GitHub actions. Binaries themselves are built using Caddy's main.go, you can see the Dockerfile used for that here
Modules Included
| Name + URL | Type | Short Description |
|---|---|---|
| Porkbun | DNS Provider | Provides DNS management capabilites for Porkbun |
| GoDaddy | DNS Provider | Provides DNS management capabilites for GoDaddy |
| Namecheap | DNS Provider | Provides DNS management capabilites for Namecheap |
| Cloudflare | DNS Provider | Provides DNS management capabilites for Cloudflare |
| Vercel | DNS Provider | Provides DNS management capabilites for Vercel |
| DDNSS | DNS Provider | Provides DNS management capabilities for DDNSS.de |
| MailInABox | DNS Provider | Provides DNS management capabilities for MailInABox |
| Coraza WAF for Caddy | Security | High-Performance Web Application Firewall for Caddy |
| Caddy Crowdsec Bouncer | Security | Bouncer for Crowdsec, makes decisions and denies connections in case IP is banned |
| Layer4 | Security | Provides extra filtering capabilites for Layer 4 applications with Caddy Bouncer |
| Caddy DynamicDNS | Utility | Keeps your DNS pointed to your machine |
| Caddy Umami | Utility | Umami analytics on any site without needing to modify or add extra scripts to your site |
| Image(s) | Tag(s) | Description | Architectures | |
|---|---|---|---|---|
| qor-caddy | latest-alpine, [version]-alpine | Lower file-size, uses Alpine image as it's base | x86_64, x86, ARM64 | ARMv7, ARMv6, powerpc64le, riscv64, s390x |
| qor-caddy | latest-debian, [version]-debian | Bigger file-size, uses Debian image as it's base | x86_64, x86, ARM64 | ARMv7, ARMv5, powerpc64le, mips64le, s390x |
Sadly, my testing capabilities are limited to ARM64 and x86_64, I technically have a ARMv6 device somewhere but don't have proper tools to properly prepare it for testing. General consensus is, ARM builds and x86 builds should work fine, the rest of the architectures are provided as-is but would still be helpful hearing about potential issues while running my image on those architectures.
| Directory | Tag(s) | Description | Architectures |
|---|---|---|---|
| 📁 caddy-dfs-CC | latest-debian, latest-alpine, cc-caddy-binary | Built QoR-Caddy image with modules shown above. Dockerfiles are seperated for GitHub Cross-Compilation support with golang | x86_64, x86, ARM64v8, ARMv7, ARMv6, ARMv5, riscv64, mips64le, powerpc64le, s390x |
| 📁 caddy-dfs-sarch | latest | Merged together Dockerfile-Helper + Dockerfile-Alpine /or Dockerfile-Debian that doesn't depend on GitHub actions | Host dependant |
| 📁 legacy/xcaddy | xcaddy-interactive, xcaddy-noninteractive | Interactive and non-interactive xcaddy builders that are made to quickly build Caddy with any modules | Host dependant |
Legend:
- dfs: dockerfiles
- CC: cross-compile
- sarch: single-arch, no cc
❔ cc-caddy-binary is built from Dockerfile-Helper in caddy-dfs-CC directory
❔ legacy folder includes all prior work and scripts that were used to build previous versions of qor-caddy images.
Images use following versioning: vX.YZ.HH
- XX includes version type, 0 is considered "beta" or "semi-stable"
- YY includes Major changes
- ZZ includes Minor changes
- HH includes Patches, Version bumps & Fixes
They will always be one higher than the previous ex. if a patch releases and prev version was v0.16.0, the next one will be v0.16.1.
Exception being anything past version v0.30.0 will change to v1.0.0 "release"
| Env | Description | Value |
|---|---|---|
CADDY_ENVIRONMENT |
Controls what type of environment Caddy is in. If it's in testing, automatic config reload is permitted, if not then it's not. If this value is empty, it will fallback to PROD |
PROD or TEST |
CONFIG_PATH |
Points Caddy to the configuration file, must be a valid path where the file is present. It is recommended to map a volume with the config file in /app/configs |
/app/configs/Caddyfile |
EXTRA_ARGUMENTS |
You can pass here any extra runtime flag/launch parameter to the Caddy binary, useful for some extra specific options when running as TEST environment. This variable can be empty if none are desired |
|
Since v0.19.1, ADAPTER_TYPE has been dropped from being required. This was due to very smol oversight where you would be unable to use normal caddy.json if this was set to anything. In case you still need the functionality, it's recommended to make use of EXTRA_ARGUMENTS instead
See here
See here
See here
If you ever used Caddy, it's about the same. You'll mostly be sitting in Caddyfile configuring things and what not. It is however recommended to enable admin endpoint as that will allow you to issue commands such as caddy reload to the container and many other commands such as caddy test.
When it comes to usage of extra modules included here, you should seek that out yourself as I feel like they've already done pretty nice job of documenting their own usage on their repositories. Though, Setup.md might have configuration examples
In order to reload a configuration file, you can run podman exec -t CONTAINERNAME /app/bin/caddy -c /app/configs/Caddyfile (replace podman with docker in case you're running Docker)
Feel free to do so if you feel like something is wrong, just explain why as I'm still taking jabs at Dockerfile so I might not understand few things still. It might be better to make a issue first though - Github repository