but in fact caddy 1 WAS easy and very much so, I mean it has never been easier for me to at least just prop up a caddy along with PHP for a quick little debug test webserver compared to what I used before. no super complicated and spread out apache/xampp configs, crazy annoying update procedures, NOTHING.
when you just want a simple webserver caddy was excactly that (ignoring that time period where I had to compile caddy myself, lol)
and it made a lot of development stuff easier. a new PHP version is out, okay just let me close on CGI and start the other boom you’re in, oh a new version of caddy came out? close caddy, replace binary, start again, at the very least on windows the webserver did not feel like a burden, and granted once caddy 2 is properly set up, it’s the same but setup just feels at least a little bit least comfortable than before.
also regarding the docs, they are due to caddy2 being still young obviously not overly refined and especially on the caddyfile side, not always complete, like for example it is said that markdown can be done using the templates command/directive/whatever but HOW?
this does not really say how to do markdown with this at all, while in caddy1 there was a wonderfully documented mardown option that couldnt be simpler, add your path, and maybe add some extras for flavor but dead simple if you want
Hi,
I didn’t know about v1 and I know what it is to start from the ground when you already have a working tool (there a bit of feelings to deal with…).
That said, I spend a lot of time to understand the v2 logic (it is high level and it does not mean easy level). It can be frustrating but not for long as the doc helps a lot (I don’t have production site with specifics need, it’s a lot easier I know).
The docs still need some more examples (but not too much), I could have save some time with it (even if the practice I had is not useless anyway).
I can help for that! What kind of examples do you want? (I can even translate in french if needed).
As a memo for myself, I’m using this server:caddy [« Wikidd »] (in french for now)
Another attempt in english : caddy [« Wikidd »]
If it’s helpful, I would be glad to write up some generic examples (maybe not only the Caddyfile).
My use case is running a PHP web server with CORS enabled. The v1 cors plugin syntax is easier to read: cors / {website}
than v2, which is:
headers / {
Access-Control-Allow-Origin {website}
-Server
}
This also applies to the ipfilter plugin. I prefer shorter syntax to address these features.
I am running a few sites on v1, and would like to have access to the documentation in the future. The v1 website says it will go away soon. Why? Unless there are security implications, v1 shouldn’t be marked as obsolete. I would like to continue working with v1.
FYI you need to remove the / for that to apply to all paths. v2 path matching is exact match. This is all explained in the Upgrade Guide:
We’re working on it. v2 just came out, examples don’t just appear out of the blue, it takes time and users to come up with decently representative examples from working configurations.
We’re pointing people to the wiki on this very forum as the ideal place for examples and guides:
Are you talking about these pages?
Because those are definitely tutorials. They even appear under the “Tutorials” section in the sidebar.
What is missing from the new tutorial? https://caddyserver.com/docs/caddyfile-tutorial - it was based on the old one and contains nearly analogous information, even in a parallel presentation (obviously with a few changes/improvements).
Is this referring to the Getting Started tutorial now? Getting Started — Caddy Documentation – these are crucial for understanding your new web serer. One thing I am pretty convinced about is that users need to understand these aspects of Caddy because it is so unique from other servers.
Caddy 2 is not a toy; it is something that needs to be understood in order to be used well.
There’s nothing stopping anyone from writing these directives for v2 as well! (Though it is not strictly necessary to achieve the functionality due to Caddy 2’s advanced matching and header manipulation capabilities – but more directives can always be written for convenience, if desired.)
Did you know it took years before Caddy 1 had these features? I’d say we’re doing pretty well for where Caddy 2 is at, just a few weeks after its first tag.
The message in the banner is urgent to convince people to upgrade, even though we will probably have a link to a PDF of the docs or something, somewhere, at some point. I will suggest that you upgrade nonetheless, since Caddy 1 has bugs and stuff that can’t/won’t be fixed.
You can serve any static files as they are. If you mean markdown rendered as HTML, then, what use would that be? They would have no style, no page title, no behavior (optional, but still, most sites use a few lines of JS at least), no navigation, no header, no footer, etc. Markdown files are kind of useless without a template, hence the templates directive.
style and js was in caddy1 set centrally which makes sense when you do not want to modify many markdown files just to fit the template.
in fact you could even throw in a global template to use for all markdown files at a specific place allowing even more flexibility while keeping the ability to just use markdown files.
You can do the same in Caddy 2, that’s exactly how we do our docs. One file with the styles and template, then countless other Markdown files that get rendered into it.
okay that is totally not obvious that the tpl works that way. I just thought you would have to make each page as a template with places for variables like
Thanks Matt and Francis for the links and feedback! This Caddyfile (Example: WordPress) is a good starting point for my upgrade to v2. I’ve read the documentation and understand the directives better now, but in the spirit of minimal configuration, I think the v2 documentation can perhaps offer sample Caddyfiles for PHP or .NET web servers right in the beginning so users can get started quickly without having to read too much into other details.
None of us have experience with .NET, but it would probably just be a simple reverse_proxy. A .NET example would be basically meaningless.
I don’t really think we need examples specific to those things in the docs. That’s exactly what the wiki category is for. Some simple PHP examples make sense to have in the docs though, because we have a directive dedicated to it.
Now I know this is a non-popular opinion and I know that a lot of time and effort went into creating v2. When I started to learn how to use v1 and write the v1-caddyfiles, I was astonished it could be so simple. No endless number of configs to manage and it just worked. I liked the Caddyfile. Now its all just a confusing mess.
I read the documentation for migrating from v1 and was even more confused. “Why do I need an API endpoint for configuring my webserver?!” “Why is the config suddenly JSON?!” “Do I have to re-learn how to write configs in JSON now?”
If I want to use Caddyfiles, I have to convert them. I didn’t find a tool to convert v1-Caddyfiles to v2-Caddyfiles, only for v1 to JSON. This sucks. The JSON configs may be a lot more dynamic but they aren’t as good as the Caddyfiles for overviewing what it actually does!
Caddy V2 is not the next version of Caddy, it is a completely new piece of software. I want Caddy v1 back and I want it maintained. I just think it’s sad.
This is just a misunderstanding on your part @MCMainiac.
Caddy v2’s default config language is JSON, and is what it uses internally. In v2, the Caddyfile is an adapter, which is essentially syntax sugar (plus some nice magic) that translates to JSON. It’s very easy to use.
You don’t need to use JSON at all in Caddy v2, it’s just what is used internally. The docs are written such that you’re aware that that’s how Caddy works, because otherwise you would never know the depth of the power Caddy offers.
The API is necessary to allow for zero-downtime graceful reloads of Caddy when you change your configuration, in a manner that works cross-platform (Windows/Mac/Linux). The caddy reload command essentially just makes an HTTP request to the API to push new configuration.
Caddy v2 is a complete rewrite from Caddy v1, from the ground up. Caddy v1 had a huge laundry list of limitations and pitfalls that made it very complicated to solve certain usecases. A rewrite of the codebase was necessary to make it much more flexible. This unfortunately means breaking changes. We also took the opportunity to implement everything that was on our wishlist for the project for years but never had the opportunity to try because it would be too big a fundamental change to v1’s architecture at the time.
If you need help to convert your Caddyfile from v1 to v2, please open a help thread on these forums, and we’ll help you out. Posting an angry comment like this doesn’t solve anything. Please spend the time to learn why things changed.
I’m considering closing this thread, because it’s just turned into an opportunity for anyone with their misunderstandings to complain, but I don’t want to make anyone angry by doing so.
If you have any specific complaints or questions, please open a new thread instead of reviving this one.
The v1 Caddyfile is not compatible with v2. That’s why we call it v2.
Feel free to make a converter tool though! I’m sure yourself and others will be very pleased. This is how open source projects work, after all. You can complain or you can contribute. Prefer contributing.
In case you’re new to open source, here’s how it works: if you want something a certain way, you can make it that certain way! So if you want to keep maintaining v1, feel free to do so!
As you may have realised while reading my comment from earlier, I was angry because something didn’t work, went to this forum and saw a thread titled “Anyone else dislike v2?”. It wasn’t right to just complain about things. Reading through your comments here makes some decisions clearer for me.
I got the idea when I changed no config at all and just replaced the binary. On startup it complained about unknown directives. So I had to convert v1-Caddyfiles to v2-Caddyfiles.
I’m not really new to open source software projects, but I don’t have the expertise to maintain a project like caddyserver v1. Neither have I the time, nor do I have the knowledge. Consider it a cry for help which is hopefully picked up by someone more capable than me.
In any case, I think you developed software, which is very useful and became even better (in terms of quality and quantity of features) than the previous version.
So if you want to keep maintaining v1, feel free to do so!