What does HackerNews think of wedge?

https://news.ycombinator.com/item?id=36049135 | May 2023

> The docs were brilliant for v1, it wouldn't surprise me if they were the spec for a great user experience and the code came second.

I agree with this, v1 was an excellent user experience, I actually ran it on my servers for way too long. There was also the Wedge fork which might have helped with the EOL but sadly it didn't go anywhere: https://github.com/WedgeServer/wedge

> Despite v2 supporting a very similar config file, the documentation doesn't emphasise that and tries to steer you towards its API, confusing JSON config syntax etc.

Others responded to this a bit more, but while I agree that different config types are a confusing experience, at the same time I appreciate that they support something like that in the first place. I might not use it often, but it's nice that you can.

Avoiding the top Nginx configuration mistakes | Feb 2022

Expand Context ↕

I actually really like Caddy, though some of its defaults at least historically have been odd, such as responding with 200 where other web servers would respond with a 502 or something similar: https://caddy.community/t/why-does-caddy-return-an-empty-200...

Also, this is a bit of a personal preference, but v1 Caddy felt like maybe a bit easier to get started with than v2 Caddy, though sadly was abandoned. I'm sure that there were good reasons for doing it, but the few forks that started out from it with the intent to maintain it never really went everywhere, so v2 is the only possibility nowadays, unless you want to maintain it yourself or like dead software: https://github.com/WedgeServer/wedge

Of course, that's not a criticism of Caddy itself, just how we as an industry sometimes need rewrites and that makes us keep up with the churn.

Put a Fork in Caddy; It's Done | Apr 2018

This is not the first contentious decision for caddy, and it does already have a fork: https://github.com/WedgeServer/wedge

On top of that, "fast, automatic TLS HTTP2 capable web server" is not some complex feat in Go. HTTP2 is already baked into the stdlib, and you can add automatic TLS via LE in a few lines of code: https://godoc.org/golang.org/x/crypto/acme/autocert.

A few alternatives:

https://github.com/labstack/armor

https://github.com/containous/traefik

Announcing Caddy Commercial Licenses | Sep 2017

Expand Context ↕

> The company that goes and builds this themselves instead of paying a small fee for it, would be a pretty stupid company haha...

There is a fork without the adware now, so the smart company will use the fork to get rid of the stupid ads.

https://github.com/WedgeServer/wedge

Announcing Caddy Commercial Licenses | Sep 2017

Expand Context ↕

Wedge.

https://github.com/WedgeServer/wedge

Announcing Caddy Commercial Licenses | Sep 2017

> As of version 0.10.9, Caddy emits an HTTP response header, Caddy-Sponsors, which is similar to the Server header that Caddy already has, except that this one credits our sponsors who make it possible to keep Caddy free for personal use. This header cannot be removed by the Caddyfile, and its presence is required by the non-commercial EULA. This requirement is waived by the commercial license, so the header is not present in those binaries.

Really not a fan of this, guess I'll be compiling my own builds from now on.

Don't get me wrong, I think charging for commercial licenses (which come with proper support) is a good business model, but my personal site shouldn't suddenly become an advertising outlet. The fact that the headers aren't seen by most non-technical users is moot.

I find this practice pretty obnoxious to the point of looking at NGINX Plus for commercial use instead.

Edit: Here's my fork https://github.com/WedgeServer/wedge

Second edit: Accusation of trademark violation within an hour of the fork, classy! https://github.com/WedgeServer/wedge/issues/2