HomeLab/dockercompose/caddy/README.md

# 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](https://registrar.epik.com) 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
                }
        }
}
```