Why Caddy might be the best start for your next software project

Do you dread setting up a webserver for your project(s) and do you wish you could skip this altogether and it'll still magically work? Then Caddy might be the perfect webserver for your next project!

In this post, we're going to look at a few of the benefits of Caddy that instantly sold it as the replacement for Nginx and Apache. These are the topics we're going to look at:

1. What is Caddy?
2. How does Caddy compare to other webservers?
3. Why should you use Caddy for your next software project?
4. How do you get started with Caddy?

Let's dive right in and see what Caddy is all about!

What is Caddy?

Caddy is a webserver, like Nginx and Apache, that routes traffic from the internet to your application, static files, or acts as a reverse proxy.

But it's so much more than just a webserver, it also automatically generates SSL certificates for your website, takes care of caching, and its configuration is hysterically simple compared to Nginx & Apache.

Caddy takes care of the things that you dread doing in projects with Nginx and Apache. Sure, it's not difficult to set up SSL for those webservers, but it's still something you have to think about. Caddy does all this work for you, so all you have to do is point it to your application and it just works.

The Caddy team has put together an excellent illustration of what Caddy is in technical terms:

How does Caddy compare to other webservers?

So how does Caddy compare to other webservers like Nginx and Apache? I think the most important thing to look at for most developers is performance. How fast is it compared to the other webservers? There are a lot of benchmarks on the internet that compare Caddy with Nginx, for example 35 Million Hot Dogs: Benchmarking Caddy vs. Nginx. This benchmark shows something very interesting:

• Nginx is marginally faster than Caddy at serving requests
• Caddy is multi-threaded and will start to use latency when it's getting hit with massive numbers of HTTP requests...but it will never fail to fulfill the request.
• Nginx is single-threaded (in this test) and will start to refuse connections once it's at its capacity
• Nginx only outperforms Caddy with a special performance-optimized configuration, while Caddy stays at a "stock" configuration

Reading that benchmark is worth your time if you're interested to learn more about the performance comparison.

I've unfortunately not been able to find a good benchmark that includes Apache as well. If I do happen to find one, I will update this and post a link to the comparison.

So if you look at the performance of Caddy compared to other available webservers, we can see that it's not just comparable with Nginx, but sometimes even outperforms it. The biggest takeaway from reading that benchmark is the fact that Caddy is so fast with a "stock configuration". You don't have to spend time trying to optimize your configuration to get excellent speeds like you would have to with Nginx. This is what I want! I want the webserver to just work and get out of my way. Caddy accomplishes this for me!

Why should you use Caddy for your next software project?

I've already mentioned a few reasons why you should use Caddy for your next software project, but let's list them again:

• It's comparable, if not faster, than Nginx
• Its configuration is incredibly simple
• You don't have to think about SSL certificates
• It's multi-threaded, so it'll actually make use of the server you're running it on

Let's add a few excellent benefits to using Caddy for your next project!

First of all, Caddy doesn't have any dependencies. It's a compiled Go binary that can run anywhere. This makes it ideal for using it in a container in your Docker or Kubernetes environment.

Secondly, it offers things like load-balancing traffic to backend services, health checks, circuit breaking, and caching out-of-the-box. For me, this is a clear benefit, because this saves a lot of time...time you can spend on building your application.

Lastly, the biggest benefit of using Caddy is that it has built-in directives for using fastcgi. This helps you to route traffic to your PHP application with a single line in your configuration file.

But how do you get started with Caddy? Let's find out!

How do you get started with Caddy?

Getting started with Caddy is simple! You can use the CLI to serve your configuration and start a server right then and there, or you can use Docker. I prefer to use Docker because it fits perfectly in my projects like that.

Let's look at the configuration to serve traffic to our PHP/Laravel application:

(laravel) {
    root * /var/www/html/public
    encode zstd gzip
    file_server
}

(redirect_clean_url) {
    handle_path /index.php* {
        redir {uri} permanent
    }
}

:8000 {
    import laravel
    import redirect_clean_url

    handle {
        try_files {path} {path}/ /index.php?{query}
        php_fastcgi my_php_fpm_backend:9000
    }
}

The code block starting with (laravel) and (redirect_clean_url) are snippets, essentially reusable blocks of configuration that you can apply to any configuration by importing them: "import laravel" and "import redirect_clean_url". If you've hosted a Laravel application before, you'll know that you have to route all traffic to the index.php file in the public folder of your project. The "laravel" snippet sets the document route to that public folder, enables gzip and zstd encoding, and tells Caddy to serve static files from the public folder (images, css files, etc.).

The redirect_clean_url snippet is an important snippet to improve the SEO of your application. Routing all traffic to your index.php file is great, but it also causes a problem: both https://example.com and https://example.com/index.php are valid paths. This causes ugly URLs (https://example.com/index.php/blog for example) and Google could mark this as duplicate content. To prevent all of this, we want to redirect all traffic from /index.php to a clean URL without index.php in it. This snippet takes care of redirecting /index.php/blog to /blog. It does this with a 301: take note of the "permanent" keyword.

The ":8000" code block is our actual website, in this case, localhost:8000. You can also replace this with example.com and it'll automatically generate SSL certificates for your domain and serve it through HTTPS. In the handle code block, we're telling Caddy to look for static files first and if it can't find those, redirect the traffic to the index.php in the public folder. When the traffic is routed to PHP, you can specify the FPM backend using the "php_fastcgi" directive. In my case, this routes the traffic to a PHP-FPM container in the same docker environment, but this could also be http://127.0.0.1:9000 or any other place you're running your FPM server.

Now you've got a fully functional webserver for your PHP application including an SSL certificate. That's really it. You're done. It's that easy.

The simplicity of this configuration file, the excellent performance of the web server, and the fantastic documentation make Caddy my preferred webserver.

Conclusion

Caddy is an excellent web server for several reasons: it's comparable to Nginx in terms of speed, its configuration is much simpler, and it doesn't require any thought about SSL certificates. It takes all the tedious work away when setting up a webserver and helps you to get back to developing your application or website! If you're looking for a new web server for your next project, look no further than Caddy.