paint-brush
Comparing Nginx and Caddy: Configuring Wildcard Subdomainsby@russell11
119 reads

Comparing Nginx and Caddy: Configuring Wildcard Subdomains

by RussellApril 5th, 2024
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

A common use case for wildcard subdomains is in multitenant applications where each customer accesses the application from their unique domain. Manually configuring each subdomain is impractical in this scenario. In this article, we will look at configuring wildcard subdomains on Nginx and Caddy and compare both options.
featured image - Comparing Nginx and Caddy: Configuring Wildcard Subdomains
Russell HackerNoon profile picture

Introduction

Wildcard subdomains allow you to dynamically handle multiple subdomains under a parent domain without explicitly defining the configuration for each subdomain.

An illustration of a multitenant application with subdomains

A common use case for wildcard subdomains is in multitenant applications where each customer accesses the application from their unique domain. Manually configuring each subdomain is impractical in this scenario.


In this article, we will look at configuring wildcard subdomains on Nginx and Caddy and compare both options.

Requirements

  • The article assumes you have Nginx and Caddy installed.

Nginx Configuration

To get started, we'll create a new config file. You need root access to update the configuration, so we will prefix the command with sudo.

sudo nano /etc/nginx/sites-available/app.com


Add the following configuration to the file:

server {

    server_name *.app.com;

    location / {
        proxy_pass http://127.0.0.1:8090;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

This configuration proxies all requests to a service running on port 8090. The key bit is server_name *.app.com; this tells nginx to handle all requests made to *.app.com (customer1.app.com, customer2.app.com ...).

Caddy Configuration

Just like Nginx, we'll begin by editing the main configuration file and prefixing the call with sudo since it requires root access:

sudo nano /etc/caddy/Caddyfile


And the contents:

*.app.com {
    request_body {
        max_size 10MB
    }
    reverse_proxy 127.0.0.1:8090 {
        transport http {
            read_timeout 360s
        }
    }
}

Comparison and Conclusion

Both Nginx and Caddy have similar configuration patterns; they both have distinct approaches, so the syntax differs greatly. They, however, both provide nearly the same levels of flexibility and functionality with Caddy being more akin to JSON and supporting it natively.