4 ms·

Neat! What is the benefit of using this over "standalone" nginx? The HTTP API enabling configuration change at runtime without downtime (like Caddy)? No need fo

Neat! What is the benefit of using this over "standalone" nginx? The HTTP API enabling configuration change at runtime without downtime (like Caddy)? No need for a process supervisor like supervisord or systemd as nginx Unit is managing the backends?

supriyo-biswas 2y ago
For me I'd rather ship a single binary with PHP support in it when using containers.
- la_fayette 2y ago
  Can you elaborate on that? Especially, where is the php runtime and the webserver?
9dev 2y ago
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. 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.
- SahAssar 2y ago
  What is caddys language runtime? Which languages does it support? Or are you thinking of the frankenphp plugin?
  - 9dev 2y ago
    Caddy can either use something sophisticated like FrankenPHP, which I very much look forward to using soon now that it seems stable, or a regular old FastCGI SAPI.
    - SahAssar 2y ago
      But nginx also supports FastCGI, and you need to run the FastCGI server as a separate process (like php-fpm), right? 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.
      - chuckadams 2y ago
        Unit has its own SAPI for PHP and executes it directly, no php-fpm needed. I’m using it to serve Wordpress right now, works pretty well.
        SahAssar 2y ago
        Right, but the parent comment seemed to imply that the same was true for caddy. I was asking what caddys language runtime was (besides via plugins like frankenphp)?
        chuckadams 2y ago
        Plugins would be it, so you could say Go is Caddy's runtime. Which is of course duh, but since the official mechanism to extend it is by statically compiling in go code, it's also accurate. It's not like nginx and apache are that much different, their "language runtimes" also boil down either to extensions linked into the server or proxying to a backend through another protocol like FastCGI. Caddy supports fcgi out of the box, even using PHP's default settings with one line of config, but I'm not a big fan of php-fpm, and I like having just one daemon to supervise.
        SahAssar 2y ago
attentive 2y ago
It's an app server. It can run your asgi or wsgi app.
callahad 2y ago
Exactly, they're complements: you'd deploy your application on Unit and put that behind NGINX or another reverse proxy like Caddy or Traefik. 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. ;)

supriyo-biswas 2y ago

For me I'd rather ship a single binary with PHP support in it when using containers.

la_fayette 2y ago
Can you elaborate on that? Especially, where is the php runtime and the webserver?

9dev 2y ago

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. 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.

SahAssar 2y ago
What is caddys language runtime? Which languages does it support? Or are you thinking of the frankenphp plugin?
- 9dev 2y ago
  Caddy can either use something sophisticated like FrankenPHP, which I very much look forward to using soon now that it seems stable, or a regular old FastCGI SAPI.
  - SahAssar 2y ago
    But nginx also supports FastCGI, and you need to run the FastCGI server as a separate process (like php-fpm), right? 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.
    - chuckadams 2y ago
      Unit has its own SAPI for PHP and executes it directly, no php-fpm needed. I’m using it to serve Wordpress right now, works pretty well.
      - SahAssar 2y ago
        Right, but the parent comment seemed to imply that the same was true for caddy. I was asking what caddys language runtime was (besides via plugins like frankenphp)?
        chuckadams 2y ago
        Plugins would be it, so you could say Go is Caddy's runtime. Which is of course duh, but since the official mechanism to extend it is by statically compiling in go code, it's also accurate. It's not like nginx and apache are that much different, their "language runtimes" also boil down either to extensions linked into the server or proxying to a backend through another protocol like FastCGI. Caddy supports fcgi out of the box, even using PHP's default settings with one line of config, but I'm not a big fan of php-fpm, and I like having just one daemon to supervise.
        SahAssar 2y ago

attentive 2y ago

It's an app server. It can run your asgi or wsgi app.

callahad 2y ago

Exactly, they're complements: you'd deploy your application on Unit and put that behind NGINX or another reverse proxy like Caddy or Traefik. 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. ;)