Over the last year, a bunch of feature requests have cropped up in GitHub issues. But some features don’t belong in Caddy core, so we made Caddy extensible with plugins. I’ve closed those issues but am linking to them here so they are not lost.
If you’re a Go developer that would like to extend Caddy’s functionality, please feel free to build these plugins and share them with the world!
We can use this thread as a collection point for plugin requests, but if you are actively developing a Caddy plugin and would like to track its progress and talk code, please open an issue on GitHub! Thanks—we want to keep all specific dev-related discussion on GitHub.
Adding a new plugin idea
Make sure it has not already been proposed
Include specific, concrete details with enough information so that someone who is interested in building it can act on your idea.
Discussing a specific idea
If you want to further discuss a plugin idea or reply to one, click “Reply as linked topic” to start a new thread. Let’s keep this thread on-topic.
These are ordered roughly oldest to newest (descending).
Caches a path for X amount of time based on settings.
cache /assets {
ttl 86400
cache_path assets
}
Description ttl - How long to cache for cache_path - Where to store cache.
Default storage location would be in the .caddy/cache/ folder if relative path is used.
So in the example above assets would be cached in .caddy/cache/assets
This would work really well when proxying storage services like B2/GCS/S3 due to the cost of egress for those services.
There are 2 ideas floating around and I had no time yet to get to them. Perhaps someone else is faster:
Redirect plugin using DNS TXT records:
TXT records such as: “302;https://example.com”
Or: “302;https://example.com/{uri}”
On an incoming request the plugin would request the _redirect.$host TXT record and redirect the request accordingly. This has rudimentary caching due to how DNS works.
Rewrite plugin:
Ability to rewrite strings within the response body. example.com → cdn.example.com and maybe even more via an additional regexp option.
The redirect idea is close to me, because I run a DNS-redirect service (serves HTTPS over caddy, maintains configuration in a yml file) called lightsaber.
However, I really like the idea of setting up the config itself in a TXT record (instead of a public yml file). I’m going to work on integrating that into lightsaber first.
Awesome to hear, that it’s not just me that thinks having the redirect config collocated with the actual DNS records might be great. I’ll try to get my preliminary thoughts on the TXT formate to you as an issue in lightsaber for now and even so I might not have time yet to help with the implementation I would love to contribute my thoughts and a second set of eyes, where possible.