Caddy server

[dumprop]

Summary

Caddy seems more stable, than in 2017

Motivation

I want to replace nginx/apache by caddy

Additional context

#315

[andryyy]

We will probably not change to Caddy. I simply don't see a reason to do that. It will break many setups, all custom Nginx sites will be useless or would need to migrated... for what?

There is no way we could support every httpd on this planet to satisfy everyones needs. :(

[dumprop]

It has better TLS configuration, easier operation and written in Go (so, it should be more secure w/ same speed) In general, I do not need this support urgently (fortunately is possible to set up reverse proxy to nginx), but I would like to have this opportunity out of the box (remove unnecessary nginx) I think it more stable after a few years

[high3eam]

@dumprop Caddy is a great web server, and it performs really well as a reverse proxy in front of Mailcow. No need to replace the nginx-mailcow container.

I run multiple sites and services behind Caddy and your configuration could look like this:

#########################################################################################
# Webapps using reverse proxy                                                           #
#########################################################################################


(proxyAppendix) {
        tls [email protected]
        header * {
                Server "Caddy/v2"
                -x-powered-by
        }
        encode zstd gzip
}
mail.example.com,  autodiscover.example.com, autoconfig.example.com {
        reverse_proxy * 127.0.0.1:8000
        import proxyAppendix
}


#########################################################################################
# Standalone webapps                                                                    #
#########################################################################################


(header-fileserver) {
        header * {
                Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"
                X-XSS-Protection "1; mode=block"
                X-Content-Type-Options "nosniff"
                X-Frame-Options "SAMEORIGIN"
                Server "Caddy/v2"
                -x-powered-by
        }
        encode zstd gzip
        file_server
}
1.2.3.4:80, [IPv6]:80 {
        redir https://example.com{uri} 301
}
example.com, www.example.com {
        root * /var/www/html
        respond /ping "Pong!"
        tls [email protected]
        php_fastcgi unix//run/php/php8.0-fpm.sock
        import header-fileserver
}

[Adorfer]

i do not see any stability issues with nginx in mailcow-dockerized. please show how to reproduce the issue.

[andryyy]

I really doubt Nginx is less stable. Caddy is great, but that's just not what we decided to use. If we used Caddy, we would have been blamed why we didn't use Nginx. :)

I cannot see the benefit. We would break so many existing installations with customizations for what?

TLS is not badly implemented in Nginx.

[Adorfer]

i still don't get the purpose of this issue: a) if it's about stability of ngingx in mailcow-dockerised: Please describe how to reproduce the issue. b) if it's about formance/scalabilty of ngingx in mailcow-dockerised: Please show by a a/b comparison stats that "caddy" is a remedy of the problems you are facing. c) in case it's something like "caddy is more fancy|i am a big fan": Please submit a PR and people will look into it including migration for (existing) customized setups, eg. with additional hosted sites.

[dumprop]

More easy configuration and cool TLS out of the box Also seems it more safe/stable because written in memory safe Go

I think every user should select: caddy or nginx :) So, nothing breaks

how to reproduce the issue

I have no problems w/ nginx

problems you are facing

It more like "caddy is more fancy|i am a big fan" So, in my deployment would be better to use it

including migration for (existing) customized setups, eg. with additional hosted sites.

I think nobody will do that. Only clear setup

[patschi]

nginx is a stable, well-battle-tested webserver used in many private, and enterprise-IT environments, is safe, fast and easy to use. There's no reason completely revamping everything to switch and migrate every single installation to Caddy without having any real benefits coming with it.

I think nobody will do that. Only clear setup

That doesn't make sense. You can't have thousands of nginx AND Caddy setups mixed out there. What happens when new sites are added (like XMPP)? What happens to the acme container and its configuration as well as the definition in the docker-compose file? Beside that, all this has to be well-tested.

You need some kind of baseline which you rely on and you can support. If you do drastic changes or unsupported things, you're in an unsupported state and strange things might happen.

If you would like to have Caddy as your frontend-webserver, you can easily go ahead reverse proxying to mailcow via your Caddy webserver. (I'm pretty sure Caddy can play as reverse proxy)

[Adorfer]

Only clear setup

@dumprop Feel free to provide a PR so it's possible to benchmark the benefits.

[navossoc]

Off the top of my head:

• Caddy provides on-demand TLS.

This may help to issue certificates for newly added domains.

Additionally the domains DNS configuration should be reviewed. Once the DNS configuration is approved, restart "acme-mailcow" to automatically generate certificates for your new domain (autoconfig., autodiscover.). This step is optional and will be retried every 24 hours.

I'm not saying you need to change it, but this is a cool feature that nginx lacks. Probably I'll try to add it to the stack, so I can drop the acme container...

(I just set up a test server, so I'm in no position to say if that is really possible without creating a black hole and breaking everything :rofl:, but I'll get there when I got more familiar with the project)