For example v2ray is also configured with complicated json, but they made things like that: https://tools.sprov.xyz/v2ray/
https://veekxt.com/utils/v2ray_gen
You just choose options you need and it generates the config for you.
For a now configuration of caddy 2 looks horribly complicated (no offences);
And you say you make it easy with caddyfile adapter but all caddyfiles I write, all of them are failed to parse, it’s not real caddyfile anymore, because it is not compatible, so it’s not easy to migrate for people like me who uses caddy 1 in production and going to migrate to caddy 2.
I think simple interface to generate configuration would be a perfect solution. Please let me know what you think about that.
1 Like
I’m sure none will be taken by the developers in this regard - this is an acknowledged side effect of how incredibly robust and powerful Caddy v2 is, and just how much you can configure.
Yeah, the v1 Caddyfile has some marked differences from v2. Mostly, though, this is about the fact that the directives are different, and the fundamental differences with matchers and middleware. I don’t think cross-compatibility is a goal in the slightest. The only point of the v2 Caddyfile is to keep a simple option for working with Caddy. You’re still definitely not working with Caddy v1 anymore.
The downside to any config generator is that it has to make some assumptions about what the best way to configure the app will be, and that almost no interface is going to expose all the capabilities of Caddy. But I think it should be pretty doable for simple use cases. Generating JSON might be a bit difficult to re-engineer, but I figure you could have a basic interface generate a v2 Caddyfile and then use Caddy’s config adapter for the JSON version.
Those two config generators you posted look like they were simply put together in HTML/JavaScript by third parties. Should be pretty easy to write something similar for Caddy v2 conf. If you or anyone else puts out a tool like that, make sure to post it here on the forums!
Hi Andrey, thanks for your feedback.
No offense taken, I’m flattered actually 
This is intentional, see: https://github.com/caddyserver/caddy/tree/v2#caddy-2-feels-harder-to-use-how-is-this-an-improvement-over-caddy-1
Caddy’s ease of use is one of the main reasons it is special. We are not taking that away in Caddy 2, but first we had to be sure to tackle the fundamental design limitations with Caddy 1. Usability can then be layered on top. This approach has several advantages which we discuss in the next question.
Caddy 1 had many limitations that we had to overcome by exposing more surface area for configuration (and an all-new design to make this possible).
Now that we’ve solved those design flaws, we are finishing filling out the rest of Caddy 2’s basic functionality like logging, error handling, etc. Once that is done, we will make sure it is still simple on the surface for basic things.
As @Whitestrake mentioned, v2 is v2 because it is not backward-compatible with v1. But that does not mean v2 is “hard.” v2 is still easy to use and the Caddyfile is mostly unchanged, except some of the directives are a little different.
But the fundamental benefits and structure of the Caddyfile are the same. Less has changed than you might think, but we’ve also solved some of the biggest problems with the Caddyfile. Before the stable release, we’ll have a migration guide explaining what is different, and have a tutorial for the new Caddyfile syntax.
It is most definitely “real caddyfile”, in fact, it will soon be the only Caddyfile! The v2 Caddyfile has many improvements and preserves the same easy-to-use core values: simply put your site address, then on each line describe a feature you want your site to have.
Compatibility is orthogonal to ease of use. Remember that you only have to make the upgrade once, and Caddy 2 is designed to have a much longer lifespan.
Ah, that’s because you’re an early adopter 
We just haven’t finished the migration guide yet.
I think this is a great idea! We have plans for an official UI but in order to allocate resources for its development, we either need a company with this specific need willing to pay for its development, or a serious community-collaborative effort to bring one together. (It’s not a small/easy task.)
Well I’m personally a react front-end developer and thing like this is a work for few days (simple basic version). I would spend more for diving into specification. Now i can’t even write new caddyfile :D. I have lack of time, but if there would be few people to help (design, someone who understands specification) i would agree to collaborate. If you mean something like that but official, then maybe you should look for sponsors.
1 Like
Oh, we are! Sponsor @mholt on GitHub Sponsors · GitHub
The more sponsorships we get, the longer I will be able to work on Caddy full-time (which I do already, so uh, yeah sponsors would help a lot). That would include work polishing a UI for Caddy config.