3.7 KiB

Caddy

Explaination

Caddy exposes ports 80 and 443 on the server it is running on.

80 ==> http
443 ==> https

When Caddy receives a request directed at one of your urls, it will redirect that to the appropriate back-end service. It will also automatically configure SSL (which enables https) for services that otherwise wouldn't have it.

Prerequisites

Ports

Caddy needs the ports 80 and 443 - do not change them like you might with other containers. This also means that you want your service exposed publically so that you can access your services outside of your network. You will want to port-forward those ports to your server.

Domain Name

Register a domain name of your choice. I recommend using Epik for this (since they fully support wildcard domains).

Once you buy a domain name, you are going to create an A host record. This record will look something like below. It forwards your domain name to another IP address.

Host:       gitea.veritablevalor.com
Points to:  144.202.71.63

(Note: In the above host entry, 'gitea' is the subdomain, and 'veritablevalor' is the domain)

Now when a computer tries to contact the host above, it will resolve to that IP address - my server (which has ports 80 and 443 ready to go).

Wild Card Domains

A wild card domain is a domain name that matches anything with a certain specificity. For example, if I had an A record like below...

Host:       *.veritablevalor.com
Points to:  144.202.71.63

...then any request ending in the domain name veritablevalor.com would be redirected/resolved to 144.202.71.63. All of the entries below would point to my server.

gitea.veritablevalor.com
nextcloud.veritablevalor.com
adwfageawdawd.veritablevalor.com
rob-boss.veritablevalor.com

A wild card domain record allows you to implicitly register any arbitrary subdomain to a specific server.

Caddyfile

Below are some examples for configuring Caddy with the Caddyfile. These are by no means exhaustive - just what I use and am familier with.

Example 1: Basic Reverse Proxy

This will redirect requests to the below url to the internal address below - 10.0.10.21:3333

cyberchef.veritablevalor.com {
        reverse_proxy 10.0.10.21:3333
}

With the above setup, if you were to visit https://cyberchef.veritablevalor.com you would land on the same webpage as if you visited http://10.0.10.21:3333 (within my network). The key differences are you no longer have to remember an IP address and port, you have https (SSL) so the connection to the service is encrypted, and the service can be publically accessible with extra port forwarding for each service.

Example 2: Reverse Proxy that only permits LAN devices

This is similar to the above, but if the requester's IP address is outside of my LAN subnet (10.0.0.0/8), they will recieve a "Not Permitted" error 403 message. This effectively means that only LAN devices can use the service connected to "home.veritablevalor.com".

home.veritablevalor.com {
        reverse_proxy 10.0.10.21:5005
        @blocked not remote_ip 10.0.0.0/8
        respond @blocked "Not permitted" 403
}

Example 3: Reverse Proxy to an https service

If the service you are redirecting to already has https enabled, you should ideally disable https on that service and let Caddy handle SSL certificates. If this is not an option, you can use the below Caddyfile snipet to point to an internal https service.

nextcloud.veritablevalor.com {
        reverse_proxy 10.0.10.21:4433 {
                transport http {
                        tls_insecure_skip_verify
                }
        }
}