It supports http2 out of the box and will keep improving as the go net/http library does, performance is good (certainly good enough for 99.9% of the static sites out there, I haven't specifically benchmarked against nginx but response times didn't change much). I'd recommend it as a proxy if you need one, particularly if you need one that handles your tls certs.

But seriously, for all "hobby" projects I've started recently, and even some production services now, I go straight to caddy.

My config consists of a 1 line global config file:

    import sites-enabled/*

    example.com {
      proxy / http://localhost:5000 {
        header_upstream Host {host}
      }
    }

I've never noticed any performance issues, I think I saw a benchmark where it said caddy can handle 2000req/s, which is at least an order of magnitude or 2 faster than any upstream service I've used it in front of.

Those are application level numbers (e.g. with logic and all).

Caddy should be able to handle an order of magnitude more req/s than that easily.

It was slightly slower than nginx, but not enough to impact typical applications

I'm sure HN would love a more in-depth comment where you say how you're accomplishing things today and what you expect out of general purpose reverse proxies, etc.

https://www.techempower.com/benchmarks/#section=data-r12&hw=...

This is on Dell R720xd dual-Xeon E5 v2 + 10 GbE. Now if I chose technology that cuts this performance 200x times I am wasting resources.

I like to idea of Caddy but before we can consider using it in production I need to make sure it can keep up with the performance requirement we got.

File-serving performance — not so good.

Is that factual, or also something you feel like?

To us simple folks, you know, it looks as if Caddy has a number of use cases where it's a much neater fit than nginx. We like the extreme simplicity and the transparency of it all. Some of us also like the Go it's written in. What with the magic Go modularity, you can actually embed this server in your web-app. Or is it the other way round? Comes in handy, at any rate.

It's the other way round.

You can embed your app in the server if you want to get its features for free, though given it uses net/http and most of the features are exposed there you should probably just use that directly instead if you are doing anything significant.

Caddy isn't the universal solution, but it sounds like you're rationalizing using the more complex tool because you know it and have been using it rather than because it's necessarily superior.

Every single thing I've done, could be implemented in an opinionated away by the web server. I'd love to just say "php" and have it do the right thing.

In fact, I'd go as far as to say, it would be amazing if I could just say "proxy ____ drupal" instead of php, and it'll add the drupal rules as well.

I can set up both nginx and apache (and get paid for it), I've automated LE for new sites via ansible, etc. Nowadays if I can do with caddy, I just use that and proceed to the next task. Also remember that easy (and short) configuration means easier maintenance.

Devs also love it, they can develop locally using advanced functionality (e.g proxying an API that doesn't provide CORS).

Go is ona average 3x slower than C according to bechmarks, and it's hard to get rid of this issue because of how the language is architected. I just don't see Caddy as a possible long term replacement for nginx.