Nginx Unit: open-source, lightweight and versatile application runtime
unit.nginx.org
unit.nginx.org
/home/me/project/caddy
/home/me/project/Caddyfile
But then it... just works. Try the same with most other web servers/proxies and you're in for a world of pain. Having this much functionality bundled into a single binary is as much a curse as it is a blessing.
That said, having your own little 'Cloudflare Workers' in the form of Nginx Unit with wasm sounds great. Not sure Caddy can do that.
Sure we already have repeatable infrastructure, containers, etc. but I also love the idea of just building and shipping a PHP app binary that includes the webserver. It makes server provisioning even less of a priority, especially if I have reasons to not use serverless or PaaS tools.
Now that single binary deployment requires you to compile the software yourself. Caddy has nice tooling for this but it'd be far more convenient to just drop a dll/so file in the right directory.
Single binary deployments are great if someone else did the compiling for you. If you need to compile yourself it truly does not matter if you need to ship a single binary or a directory or whatever.
https://github.com/Radiergummi/iss-metrics/blob/main/caddy/C...
I was in the same boat as you and wanted to try out what Caddy is capable of. I was immediately convinced. So many features, where you expect them. Consistent configuration language. Environment interpolation, everywhere. Flexible API. It’s really all there.
Set the config up with CI/CD and can now just edit the config and git push knowing Caddy will just handle the rest
All of this is more or less doable with nginx, I’ve done it often enough. But read the Caddyfile and tell me this isn’t miles ahead in clarity.
I don't use docker so I don't care.
So no setting up unattended-upgrades and forgetting about it.
also totally non-standard, apt unattended-upgrades won't be doing that for you.
sure you can do a cronjob, but, non-standard
Caddy really is the most pleasant webserver software I’ve ever used.
In 2024 people are more likely to turn the cloud knob up to pay for throughput (if they need it) and save on dev time with the comparably better dev ex that caddy offers.
This seems like a weird trade off to me.
The "learning tax" is really only paid once with nginx. Once you understand how it works and configured a reasonably end-to-end example with it then you can carry that over to your next project with minimal changes.
I've hosted countless Flask, Django, Rails, etc. apps over the years and very little changes on the nginx side of things. I'd rather learn this tool once and have better runtime performance all the time across all projects.
With that said, the performance difference probably won't be very noticeable for most sites but still, I personally wouldn't want to give in to running a less efficient solution when I know a more efficient solution exists right around corner that requires no application code changes to use -- just a little elbow grease to configure nginx once. This is especially true when nginx has a ~20 year track record of stability and efficiency.
I always find this a weird selling point, TBH.
It's probably a selling point for people who don't already know the existing $FOO.
For me, putting effort into learning the new thing only to use it exactly as the old thing is wasted effort.
I don't know what I gain by moving to the new $FOO, usually.
I would wager the vast majority of Nginx "installs" are running in a container now a days.
The distro doesnt matter and few are provisioning an instance of anything, that's some container orchestration job.
Last week trying to coax nginx to be able to set a CSP nonce in a web apps index.html which apparently meant I would need to custom build Nginx or a custom build a container with a custom built Nginx to install a plug-in to do it. This type of stuff adds up and having a bunch of stuff hidden in Nginx Plus doesn't help either.
I think Nginx is a great piece of software its just that people don't need all its offerings, they just want to host some tiny js and proxy to an API and things like caddy were built for that. The limited throughput doesnt matter when CloudFlare or Cloud front cache most of the things it is serving anyway.
As for the CSP nonce, I'm surprised that there isn't a plugin, but compiling isn't a big deal, just annoying. Alternately NGINX is scriptable or you can do it at the application level as well. If caddy is easier for you or for that use case, then that's great, use it with my blessing.
With that said, Caddy is pretty rad.
It seems like a lot of the hipster tooling dropped those things from the past and honestly it’s so much nicer to have things contained in a single file/dir or at most two. That may be a big reason why kids these days prefer them, honestly.
As for nginx itself it’s actually much better suited for high performance proxies with many conns, imo. I ran some benchmarks and the Go variants (traefik, caddy) eat a lot of memory per conn. Some of that’s unavoidable because of minimum per-goroutine stacks. Now I’m sure they’re better in many ways but I was very impressed with nginxs footprint.
See also: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html
The main difference is in how additional software is handled. Windows, because of its history with mostly third party software being installed, generally installed applications into a folder and that folder contained the application... Mostly. Uninstalling was never as simple as that might imply.
Linux distros had an existing filesystem layout (from Unix) to conform to, so when they started developing package managers, they had to support files all over the place, so they make sure packages include manifests. Want to know where use executable are? Check bin. Superuser.com executables? Check sbin (don't want those cluttering the available utils in the path of regular users). Libs for in libs.
/bin and /usr/bin and the others are holdovers from the long past when disks were small, and recent distros often symlink usr to / so they're different in name only. /usr/local is for admin local modifications that are not handled through a package. /opt is for whatever, and often used for software installed into a contained folder, like in windows.
Just know what bin, sbin, lib, opt and etc are for and most the rest is irrelevant as long as you know how to query the package manager for what files a package provides or as it what package a specific filer belongs to. If you looked I to windows and the various places it puts things I suspect you'd find it at least complicated, if not much more.
Note: what I said may not match the LSB (which someone else usefully posted) perfectly, but for the most part it should work as a simple primer.
It is annoying however, that configuration is not standardized across distros.
I'm pretty annoyed with how many people on HN are shouting in every thread "caddy is soon much better!" and the only material benefit to caddy I can glean from these threads is that it's easier for noobs. Which, to be clear, as far as I can tell, it does a good job of that and will probably win the next decade over nginx for that reason alone, but nginx really isn't that hard to set up, and I'm surprised there isn't so much push back against the pro-caddy narrative. It's just an uphill battle for an application written in golang to be faster than a mature application written in C. Obviously I will continue to use nginx until hard evidence of on-par performance is published, but at the same time I'm more likely to hold out for a competitor written in rust.
Yes but Golang can be fast on almost every aspect too with some simple tricks. The main thing is the goroutine overhead per socket, which impacts reverse proxies indeed.
> but at the same time I'm more likely to hold out for a competitor written in rust.
Rust with Tokio can keep very low overhead theoretically. But language is not everything. For instance Envoy is also quite high per-conn overhead when I checked despite C++. I assume it’s just too many knobs and features.
If someone hooks them up to a man page I think it might level the playing field.
Fun example from last week, a colleague was trying to try out ACME with a custom ACME server, and configured it. For some reason Caddy was not using it and instead used its own internal cert issuer, even if explicitly told to use the ACME provider as configured. Turns out that if you use the .local domain, Caddy will insist on using its own cert issuer even if there's an ACME provider configured. Does that make sense? Yeah, somewhat, but it's the kind of weird implicit behaviour that makes me mistrust it.
My go-tos are nginx for static stuff, Traefik for dynamic stuff.
So easy and works on everything
Contact info is in my profile.
Thinking of a typical PHP app, which exposes both dynamically routed endpoints and static asset. With a traditional setup, you’d let nginx handle all paths as static assets and fallback to the index.php file to serve the app. When you package that as a container, you’ll either have to use separate PHP-FPM and nginx containers, or run two processes in a single container. Both of which is not ideal. And it gets ever more complex with TLS, and so on.
Using unit or caddy, you can simplify this to a single container that achieves it all, easily.
I don't see how caddy (without stuff like frankenphp) is any closer to a complete single binary reverse-proxy AND language runtime than nginx.
> It’s pretty much like Caddy vs. nginx: Language runtime, static asset serving, TLS, routing and so on bundled in a single package. That makes it very easy to deploy a container, for example.
> Using unit or caddy, you can simplify this to a single container that achieves it all, easily.
With caddy this is not true, unless you have compiled in your own plugin (custom or frankenphp), right?
All I was asking is what they thought the language runtime for caddy was.
Unit can serve static assets, directly host Python / PHP / WebAssembly workloads, automatically scale worker processes on the same node, and dynamically reconfigure itself without downtime.
Unit cannot do detailed request/response rewriting, caching, compression, HTTP/2, or automatic TLS... yet. ;)
I must have been confusing it with NGINX Plus.
F5 isn't the most visible corporation in terms of grassroots engagement, but NGINX itself has remained F/OSS all these years and newer projects like the Kubernetes Ingress Controller [0], Gateway Fabric [1], and NGINX Agent [2] are all Apache 2.0 licensed. Just like Unit.
We do have commercial offerings, including the aforementioned NGINX Plus, but I think we've got a decent track record of keeping useful things open.
[0]: https://github.com/nginxinc/kubernetes-ingress
I have trauma from Aerospike, Redis, and couple of others, so it may have affected my perception.
> We’ve mapped the source config/ to /docker-entrypoint.d/ in the container; the official image uploads any .json files found there into Unit’s config section if the state is empty.
> The control API is the single source of truth about Unit’s configuration. There are no configuration files that can or should be manipulated; this is a deliberate design choice
(https://unit.nginx.org/controlapi/#no-config-files)
So yeah, the way to go is to run something like `curl -X PUT --data-binary @/config.json --unix-socket /var/run/control.unit.sock http://localhost/config/` right after you start your nginx-unit.
The way to manage a separate config step depends on how you manage to run the process nginx-unit (systemd, docker, podman, kubernetes...). Here's an example I found where the command is put in the entrypoint script of the container (see toward the end): https://blog.castopod.org/containerize-your-php-applications...
Clace manages the containers (using either Docker or Podman), with a blue-green (staged) deployment model. Within the container, you can use any language/framework.
But that's still kinda rough, so we're also overhauling our tooling, including a new (and very much still-in-development) `unitctl` CLI which you can find at https://github.com/nginx/unit/tree/master/tools/unitctl. With unitctl today, you can manually run something like `unitctl --wait-timeout-seconds=3 --wait-max-tries=4 import /opt/unit/config` to achieve the same thing, but expect further refinements as we get closer to formally releasing it.
From NGINX Unit webite: "Also on Linux-based systems, wildcard listeners can’t overlap with other listeners on the same port due to rules imposed by the kernel. For example, :8080 conflicts with 127.0.0.1:8080; in particular, this means :8080 can’t be immediately replaced by 127.0.0.1:8080 (or vice versa) without deleting it first."
Systemd (PID 1) also needs to start stopping their opening network sockets. In short, systemd now needs a systemd-socketd to arbitrate socket allocations.
I am never a fan of PROM, firmware, nor PID1 opening a network socket; it is very bad security practice.
As others have said and the team has owned up to, the current config strategy is not ideal but the Docker COPY strategy has been working well enough for my experiments.
The other somewhat annoying part of the experience for me has been logging. I would want access logs to be enabled by default and it'd be great to (somehow) more easily surface errors to stderr/out when using the unit Docker images. I know you can tap into `docker logs ...` but, IMO, it'd be ideal if you didn't have to. It's possible there's a way to do this at the config level and I just haven't come across it yet.
Also, and I know this is a bit orthogonal, but it'd be great if the wasm image exposed cargo, wasmtime, et al so you could use a single image to build, run and debug* your application. *This was a pain point for me and I got hung up on a file permissions issue for a few hours.
On the whole, though, I think it's pretty compelling and I was able to stand up Flask, Django and Rust WASM applications in short order. I'm planning to add some documentation and publish the code samples as time permits.
Is this some property required for something like your primary load balancer entry point, that can never be restarted and can’t have rollout restarts?
I have never had a problem that I would have traced back to gunicorn not working ...
On the other hand not having to run gunicorn as another separate service might be an advantage.
I'm connecting nginx to gunicorn through a unix socket too and found that to be a bit of a pain.
Years ago every website needed Apache or Nginx, then lately I've hardly used it at all... usually have a container with gunicorn behind a load balancer that is part of the cloud platform
It's easy to see how to get Nginx Unit working, but not sure exactly how it fits into the utility picture vs other options
Nginx has a lot of usecases in one package, most larger companies and more technical workplaces, use Nginx or similar alternatives.
Nginx Unit typically is meant for unifying the entire application space of multiple programming languages served by 1 Server (which also acts as a static server)
So serving golang, python, php code and application all under 1 single wsgi/asgi application server called nginx unit and be able to dynamically change its routes with api calls too.
This allows you to have 1 root process in a docker container to control your python fastapi or golang api processes, without needing 1 container for nginx and 1 container for Python/Golang process or a supervisord like init system controlling 2 or more processes inside 1 container
Everything is under nginx unit and nginx unit is being triggered as the main process inside the container.
Moreover it is also much much much more faster in terms of response time than most language dependent application servers like gunicorn/unicorn for python3, etc [1]
[1](https://medium.com/@le_moment_it/nginx-unit-discover-and-ben...)
The most time spent was building from source in Docker for ARM support and going down a rabbit hole of targeting the minor Python version that apt was installing on some Debians, w/o a virtual env, instead of the one it defaulted to.
I'm a fan. High performance, easily configurable ASGI server for so many flavors.
Basically a full stack experience from programming language, web framework and networking protocols, possibly with a management dashboard.
As for who is building one everyone that is now trying to sell the idea of packaging WebAssembly into containers, deploying them into managed Kubernetes clusters, or alternatively cloud managed applications, like Vercel, Nelify, Azure Container Apps, Cloud Run,....
Does Nginx Unit really fit into this picture though?
Is there a place for an all-in-one app server in that scenario, I would have thought they want each component to be separated (wasm host, load balancer, etc etc) for commoditisation and independent scaling of different layers
(This is not a criticism in form of a question... I am honestly curious)
Or what if you have a single logical service that's composed of a mix of Wasm endpoints and static assets augmenting a traditional Python application? Unit pulls that all together into a single, unified thing to configure and deploy.
If you're writing Node, Go, or Rust you haven't had to think about application servers for a long time. Folks writing Python and PHP still do, and WebAssembly will require the same supporting infrastructure since Wasm -- by definition -- is not a native binary format for any existing platform. :)
and my Python apps have not been behind Nginx for a long time, they're mostly wrapped in a zero-config gunicorn runner in a Docker container, static assets in S3 via a CDN
am wondering who wants a single-node heterogenous application server these days
TBH the simplicity of it is appealing though
My hope is that Unit can offer a pragmatic bridge: run your existing applications as-is, and when you want to sprinkle in some Wasm, we're ready. That's not to say Wasm is Unit's only use case, but do believe it's what will get people thinking about application servers again. :)
> my Python apps have not been behind Nginx for a long time, they're mostly wrapped in a zero-config gunicorn runner in a Docker container, static assets in S3 via a CDN
...and are there any reverse proxies, load balancers, or caches on the network path between your end user and your container? ;)
- "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.
I'd love to have something like that: provide a configuration and automatically check all the paths that the configuration enables. Maybe throw in some LLM for some comments and tips to improve performance/security.
Nginx is awful, archaic software.