Caddy is now on version 2.6 and, since its launch nearly 3 years ago, Caddy 2 development is starting to stabilize, as critical/urgent bugs are less common, and most new feature requests are best satisfied by plugins. There’s still substantial work to do to the Caddy core and the standard modules (see our open issues), but the majority of open issues are less urgent feature requests and non-critical bug reports that we can address in time as the best solutions are discovered.
Don’t misunderstand! We fully intend to fix all known bugs and continue implementing new features. I’m just saying that if you compare how busy our issue tracker was for the first 3 years of Caddy 2, to recently, things are less busy! That’s a good sign: our user base is growing substantially, (more downloads and more questions being asked about Caddy or for help with Caddy), but bug reports and feature requests are slowing down. (I’m quite busy helping sponsors and clients behind-the-scenes as well!)
As such, in 2023, I would like to focus some much-needed attention on the website, docs, wiki, community, and learning/educational material.
What’s on the top of your wishlist for our website, docs, and community? Reply here!
Congratulations on all the work, and the place you now find yourself - nicely done!
With regard to your question: This may not be a priority for you, but would certainly help me (as a new-to-Caddy, used-to-apache, not a server-software expert)…
…docs / help on how to go about properly translate re-writes in third party documentation intended for other server software, into a Caddy syntax.
For example, these instructions are for Apache and nGinx, and on the face of it are not complicated, but I can’t yet understand from the Caddy docs how to translate them into something Caddy would use: Blitz – Intelligent static page caching for lightning-fast sites.
I’m not saying the methodology isn’t able to be worked out from putting together various parts of info in the docs (I’m sure it is possible), just that I’ve been struggling to work it out. I’m less interested in “what’s the answer” and more in “how do you tackle that task, to come to an answer?” I feel like I’m missing requisite knowledge to get the job done, and that “how to translate re-writes” is likely to be a common task and useful walkthrough for people trying to “get a job done” rather than “learn Caddy first”.
Thanks for the feedback! I think that’s a great idea. Problem is, I don’t really know how to do it.
So, I could easily write a tutorial to convert those specific docs to Caddy config. But I don’t know how to generalize it in a useful way. I can give high-level ideas, like “restate what the apache/nginx config is doing in natural language, then use that to write a caddy config” – but nothing particularly helpful.
Do you have any ideas on how to make it feasible, or what these docs might look like?
At the moment for me it’s the then use that to write a caddy config bit I’m struggling with.
In this specific case I think the “apache” bit basically means:
If this is a GET request, and token is not in the query string, then return the cached file if it exists at [the path]. Otherwise hand over to the PHP process to generate that cache file.
I don’t think it’s on the shoulders of the Caddy docs to explain what Apache/nGinx configs are doing - but I do hit a bit of a wall with the current Caddy docs trying to see how I’d actually do what I believe should be done.
I’m not sure how you’d teach or show the process you yourself go through to get that answer, without it being a lot of examples of reasonably common but somewhat abstract re-write tasks alongside textual explanations. Which would be a lot of work.
That said, general tasks in re-writes are IMO things like:
Inspect a URL to then do a conditional action; so I’d need to know:
A sort of bridge-documentation / orientation. All web server software essentially has to do the same thing; but it might be modeled a bit differently in ways that are unfamiliar
Congrats on all the great work! I think we should add in Caddy docs or may be request maximum developers to include Caddy specific config. I am using this WP plugin which have Apache & Nginx conf in their docs. WordPress Cache Enabler Plugin - KeyCDN Support
Config is already available on Caddy Forum. But having it on developer site will give more visibility to Caddy and make it easy for new users to onboard.
Yeah, I agree – other sites and products should provide Caddy configs!
This one is largely out of our control because:
It’s hard to know where Caddy configs are needed around the Web.
I personally don’t use all the apps and services out there.
Our community uses more, but still doesn’t cover all of them.
Strictly speaking, we may not necessarily need to use an app to help write a config for it. But if we’re going to contribute a config, it can take a lot of time to download and learn the software, then adjust its installation to use Caddy, and make sure everything works right. Or we can just guess by taking our best stab at converting another config they already have. But then we just have to hope it’s correct…
For example, I did play around with installing Matrix, so I contributed Caddy docs. I plan to install a family Minecraft server soon, and front it with Caddy, but who knows whether I’ll be able to contribute to their docs/wikis. (Wikis are typically merit-based as opposed to open source repositories.)
Most docs out there aren’t open source. So while we can submit PRs to open-sourced docs, we’d basically have to email support or ping a developer on Twitter/email/whatever for everything else. And if it’s a wiki, well, they’re often merit-based, so it can take time to accrue reputation.
So anyway… if you see an app/service you use that doesn’t have Caddy docs, definitely advocate for or contribute them!
The point of this topic, though, is to improve our own documentation and website. So let’s see if we can discuss ideas for that instead.
Point is, as maintainers, we don’t necessarily have the bandwidth to spend more time on “spreading the good word” as is were.
And often, that’s taken as an offence by some, when you’re “self-promoting” something you’ve worked on for addition to their docs. So we have to tread carefully.
But if you’re able to spend time on helping propagate accurate information on Caddy elsewhere, that would help a lot. Feel free to ask us for help if you need to confirm accuracy of information, etc.
