Blog Documentation Try Vanilla Cloud
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options

Apache & nginx alternative: Caddy

R_JR_J Ex-FanboyMunich Admin
edited December 2020 in General Banter

I was watching that project form quite some time now and it is always getting better and better: https://caddyserver.com/

Okay, so why is it different than any other web servers? Is it faster? I don't know and I don't care! Let's be honest: for most of us, it is not important if you one web server is 2 or 3 percentages (of whatever!) faster or slower than the other. The traffic must be really high that the web server could become a bottleneck.

The most important part for me is ease of use and features. What features you ask? That's where Caddy shines: you know that https is becoming a must have (or has it already?) and with Caddy you don't need to care about that: all pages served by Caddy are served with https without you having anything to do with it. That's the main point why I noticed Caddy in the first run.

The second point is how the minimum config looks:

vanilla.mytestserver.net {
    root * /var/www/vanilla

    php_fastcgi unix//run/php/php-fpm.sock
   try_files {path} {path}/ /index.php?{query}&p={path}
   file_server
}

Beautiful, isn't it?

But it wouldn't be fair to compare the above with the example for nginx from the docs. That would need to look like that:


vanilla.mytestserver.net {
   root * /var/www/vanilla

   respond /.git/* 403
   respond /build/* 403
   respond /cache/* 403
   respond /cgi-bin/* 403
   respond /conf/* 403
   respond /tests/* 403
   respond /uploads/import/* 403
   respond /vendor/* 403

   php_fastcgi unix//run/php/php-fpm.sock
   try_files {path} {path}/ /index.php?{query}&p={path}
   file_server
}

How nice is that? And remember: always https by default :-)

Comments

  • Options
    neptronixneptronix Utah New
    edited December 2020

    This is pretty neat because it smooths out a major pain point for web developers and sysadmins. SSL certs are a PITA.

    A dev on the caddy team says the performance is pretty good: https://caddy.community/t/performance-compared-to-nginx/7993/2

    I do think they missed an opportunity for even better performance by using Go instead of C. Bummer.


    If you want really fast, try rwasa... written in 64 bit assembler... it even foregoes the use of openSSL in favor of it's own encryption engine.. and is ~2x faster and likely uses significantly less memory per request.. https://2ton.com.au/rwasa/#perftests

    I still use apache because it allows extensive custom logging. Apache creates a filtered-access.log for me which excludes all URL requests to png, gif, jpeg, css, woff, etc etc... aka file types that don't generate a load on php. filtered-access.log ONLY contains hits to the server that generate a load... and so i can pipe the result over to fail2ban and tell fail2ban that if it sees faster than 2 requests per second from an IP for 5 seconds continually, we're dealing with a bot.. so ban that bot for 30 minutes. This is MASSIVELY effective for preventing DDOS, out of control search engine bots, etc.. so i really don't mind the putzy performance/mem usage i get out of apache anymore... given that this trick reduces my peak webserver load by and allowed me to cut my hosting costs by 1/4.

  • Options
    R_JR_J Ex-Fanboy Munich Admin

    Funny thing is that I always preferred nginx over apache just because I've heard it is more performant. But now that I discovered caddy I threw away that extra speed for comfort. Since I only have test domains and nothing productive, I never needed to care for speed, anyway.

    I toy around with a lot of PHP software and writing nginx config files always was annoying. I had to search the net how to debug a config script again and again. Then there was that linking the sites-available/something.conf to sites-enabled/something.conf.


    With caddy I simply sudo nano /etc/caddy/Caddyfile and since I have written myself a global import block which includes basic auth, php, gzip, the file_server directive and logging, setting up a new domain requires four lines:

    sub.mydomain.de {
   import php_test
   root * /var/www/my-project/public
}

    For validating, I just need to enter a simple caddy validate - even I can remember that easily. At the end a sudo server caddy restart and my new ssl encrypted subdomain is up and running.



    That assembler web server sounds fun, but I wouldn't rely on a self implemented openSSL alternative. Cryptography isn't easy, assembler isn't easy and the number of people who understand both and are willing to have a thorough look at the combination of both in that web server is most probably very small.

    I love the thought of maximum optimization for speed and if I would consider to run a webserver with high traffic on a raspberry, I might consider using a piece of assembler software. But in all other cases I would not trade broad support & maintainability against web server software speed.

  • Options
    R_JR_J Ex-Fanboy Munich Admin

    By coincidence I just sumbled over this gem: https://board.asm32.info/asmbb-v2-9-has-been-released.328/

    Not everything that could be done, should be done 😁

Sign In or Register to comment.