> I had huge headaches configuring it when migrating php apps with huge htaccess rules to nginx

I also had this issue whenever I did migrations between different web applications that used different URL structures. To preserve my sanity, I now do the redirects in the application level.

I predict nginx will get a lot of competition from servers and applications written in Ru￸st. Until then, it's viable as a reverse proxy and serves static files really great.

nginx has a huge headstart though, it's stable, it's fast, has lots of modules, etc.

I'm open to competition in the field, I'm not sure the competition will emerge as fast as people think (just like competition for other well-established software bricks in general).

and already supports HTTP/2 and HTTPS.

I'm not sure it's the first one to focus on that. I remember Cherokee being really user friendly. It can't do nearly as much as Nginx, though, and there hasn't been a new release in four years so it might be dead.

On the Windows side of the world, I've found IIS to be decently user friendly to set up and administer.

I've been putting off deploying one of my side projects because I'm afraid that I'll mess up an existing site if I touch the nginx config again.

Caddy looks promising and simpler. Might have to take a look this weekend.

How is your configuration managed that this is a concern? While I generally have a whole different conf for each site run and include the directory with them in the main nginx file, you should at least have them in different blocks, even if in a monolithic config. I don't quite understand how you think you're going to break any other site.

Even if you do manage to screw up the config, just do 'nginx -s reload' - this verifies the syntax of the config and then attempts to apply it. If it is successfully applied, (e.g. dns is resolvable for listed upstreams, etc etc etc) then launches new worker processes, and then messages old worker processes running the old config to not accept any new requests (so all go to the new workers) and to shut down after finishing handling any existing requests. If it fails to apply, old workers stay up and keep running with the old config.

That said, I've found the performance to be pretty good. Getting < .01sec response times on a node.js API server that caches data in RAM. I'd expect to see worse if Caddy were a bottleneck.