We've been using Nginx Unit in production for a Python backend for about a year now and it's been working pretty well. Some thoughts in no particular order: -

We've been using Nginx Unit in production for a Python backend for about a year now and it's been working pretty well. Some thoughts in no particular order: - "Nginx Unit" is an annoying name to google when you have a problem. You get a lot of nginx results that are of course completely irrelevant to what you're looking for, as there is zero actual overlap between the two things. Using quoted search terms is not sufficient to overcome this. - When it works, the all-in-one system feels great. - However sometimes the tightly-coupled nature can be slightly annoying. For example, they publish packages for the various runtimes (ours is python) in the various registries, but only for the "defaults. Concrete example: we are currently running Ubuntu 23.04 but wanted to upgrade to Python 3.12. However Nginx Unit only pre-packages a Python 3.11 package for unit on Ubuntu 23.04 as that is the system-included Python. Had to build our own support from source, which was fairly easy, but still more difficult than our pre-Nginx Unit infra, where all I would have to do is install Python 3.12 and I'm good to go (because the python runtime wasn't at all coupled with the webserver when our stack was Nginx + Python + Gunicorn) - I never properly benchmarked the two in a comprehensive comparison, but Nginx Unit is definitely faster than the aforementioned previous stack. I tested some individual routes (our heaviest/most important) and the speedup was 20-40%. - Even when I tell it to keep a minimum number of worker processes around, it kinda seems... not to? I haven't properly tested, but sometimes it feels more like serverless, where if I haven't sent a request in a while it takes a bit of extra time to spin up a process, but after that requests are snappier. Definitely need to properly investigate this but haven't gotten around to it yet. It might just be the difference between allocated memory and not rather than spinning up processes. - It's a shame it doesn't support SSL via Let's Encrypt out-of-the-box, like Caddy. To me that is the biggest (really only) missing piece at the moment. - I much prefer using the HTTP system to manage config than files, and find the Nginx Unit JSON config much, much more readable than either Nginx or Apache configs I've worked with in the past. I'd also give it a slight edge over caddy configuration. - That said, managing the config (and system in general) can sometimes be annoyingly opaque. The error messages are somewhat terse when updating config fails, so you need to dig into the actual logs to see the error. Just feels a little cat-and-mousey when you could just tell me what the error is up-front, when I'm sending the config request. In summary, overall I've liked using Nginx Unit, but wish they would: change the name to something less confusing, add built-in Let's Encrypt support ala Caddy, and make the errors and overall stack feel a little less opaque / black boxy.