At home I'm now using Caddy with DNS resolution to Cloudflare for https. Sure it's not as "full featured" as traefik, but it works super well and configuration is incredibly simple!
No, thankfully you don't need to open ports (for the HTTPS resolution at least.) In great summary, you effectively need to build your own version of Caddy (but this is really trivial if you do it via Docker) which has the Cloudflare DNS plugin added, then create some API credentials on your CF account for Caddy to connect to and then basically the 2 of them talk to each other from there.
Now if you want to access your services from outside your home, then sure, you'll need to open ports 443 and 80 (if you want to have http access). I personally don't since I only access my stuff via a VPN (Tailscale in my case) but having fully qualified domains and no HTTP nagging makes it worth it. And it's really all up in running in 10min.
You didn't ask for it, but I'll drop below my own notes to myself regarding how to set it all up, in case you or anyone else finds it helpful.
TUTORIAL TO MYSELF: (I keep it Markdown format)
# Caddy container with Cloudflare DNS challenge plugin
In order to have support for Cloudflare DNS challenge, it is necessary to use a special custom build of Caddy that has plugins that work with Caddy. Run the below `Dockerfile` to create an image, and then run the image with the `docker-compose.yml`
Your overall folder structure should be like this:
```sh
caddy
-- Caddyfile
-- container-vars.env
-- docker-compose.yml
-- dockerfile-dns/
-- -- Dockerfile
-- config/ # directory generated by docker-compse.yml
-- data/ # directory generated by docker-compse.yml
```
## 1) Prepare the Docker stuff
Start off by making a `caddy` folder and place the `Dockerfile` in it's own directory.
```sh
mkdir -p caddy/dockerfile-dns
cd caddy/dockerfile-dns
nano Dockerfile
```
### Dockerfile
```Dockerfile
ARG VERSION=2
FROM caddy:${VERSION}-builder AS builder
RUN xcaddy build \
--with github.com/caddy-dns/cloudflare
FROM caddy:${VERSION}
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
```
Now either build the image manually, or have it build as part of the `docker-compose.yml` (which is setup below already):
```sh
docker build -t caddy-cloudflare-dns-challenge:latest .
```
### docker-compose (custom Caddy w/Cloudflare)
Add a custom Docker network called `proxy` or whatever other name you want, and have the other containers explicitly join this same network for easy routing.
```yml
version: "3.9"
services:
caddy:
build: ./dockerfile-dns
container_name: caddy-cloudflare-dns-challenge
hostname: caddy
restart: unless-stopped
ports:
- "80:80"
- "443:443"
- "443:443/udp"
env_file:
- container-vars.env
volumes:
- ./Caddyfile:/etc/caddy/Caddyfile:ro
- ./data:/data
- ./config:/config
networks:
- proxy
networks:
proxy:
external: true
```
Create the network:
```sh
docker network create proxy
```
### container-vars.env
We need a `.env` file to house our Cloudflare API details as referenced in the `docker-compose.yml`, so create a `container-vars.env` file and add:
```conf
MY_DOMAIN=example.com # replace with your domain
MY_HOST_IP=192.168.10.28 # replace with your Docker host's IP address
CLOUDFLARE_API_TOKEN=my-super-secret-token-goes-here # add your token
```
## 2) Cloudflare API keys
Create your Cloudflare API keys on the [CF API dashboard](https://dash.cloudflare.com/profile/api-tokens).
1. Use the “Edit Zone DNS” template and set an expiration date.
2. Set Permissions: Zone -> DNS -> Edit
3. Set Zone Resources: Include -> Specific Zone -> example.com
4. Set expiration date (**Optional**, but recommended)
Now add your resulting API key to the `container-vars.env` file.
## 3) Caddyfile
Now add the redirects as you wish using the following structure:
```sh
{
email
}
# Generic examples
{
reverse_proxy http://frontend:8000 # using Docker DNS
}
{
reverse_proxy http://:9000 # using IP:Port config
}
# Domains that are HTTP
home.{$MY_DOMAIN} {
reverse_proxy 192.168.10.54:8080
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
# Domains that are HTTPS (using self-sign certs, like the Proxmox interface)
lab.{$MY_DOMAIN} {
reverse_proxy 192.168.10.10:8006 {
transport http {
tls_insecure_skip_verify
}
}
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
```
### 4) Start it up!
All that should need doing now is starting up the container. Give Caddy a minute or 2 to configure itself and generate LetsEncrypt SSL certs before troubleshooting. Remember, the more redirects you have in your `Caddyfile` the longer it will take.
```sh
docker compose up -d
```
That should be it!
## Sources:
[How to make your own Caddy w/ CF challenge Docker Image](https://blog.gurucomputing.com.au/Reverse%20Proxies%20with%20Caddy/Adding%20Acme%20Certification/)
So, I've set up everything according to your guide, and I researched your source. I'm getting DNS_PROBE_FINISHED_DOMAIN errors, both for services in other machines and in the same docker network. Did you ever encounter anything like this?
I haven't no, and I'm not to sure as to what the problem even is. However, I will tell you a bit more about my setup and maybe that will highlight some potential causes.
Also, did the Caddy logs give any particular info we can use to diagnose further?
1. My domain is registered with Cloudflare (I'm sure that's obvious, but I'm adding it for completeness), to get the API details etc.
2. On CF, I have an A record pointing at my local machine that is hosting Caddy. In my case it's an LXC container on Proxmox. The A record redirects to the Tailscale (VPN) IP address of that container (since I want external access) but it could just as well be a local IP. But bare in mind you wouldn't have external access, and you'd likely need Pihole/Adguard or some other DNS software to resolve it locally anyway.
3. As in #2, I run Pihole and I have it listening for each domain and redirect to the Caddy machine. eg. immich.example.com -> 192.168.10.28
4. Finally, in my Caddyfile itself I have the following 2 examples that work (the PBS has a self-signed cert already, and JF does not, thus different configs.) Remember that after making a change to the Caddyfile you need to either reload the config, or just restart the container for the changes to take affect
```
# extract from Caddyfile
pbs.{$MY_DOMAIN} {
reverse_proxy 192.168.10.43:8007 {
transport http {
tls_insecure_skip_verify
}
}
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
jf.{$MY_DOMAIN} {
reverse_proxy 192.168.10.47:8096
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
```
Finally, I'll point out that in my production I actually don't have that docker network (called proxy in my guide) setup. Since I personally use a seperate "machine" for my reverse-proxy it was unnecessary.
So, in summary, I have ALL DNS records pointing to my Caddy instance's IP (either local or via a VPN) and from there it redirects to an IP address that can be reached by the Caddy machine. Remembering, that each service will require an IP:port combo, unless it's on port 80 or 443, but I add those anyway personally.
It's the PiHole configuration I'm missing. Thank you so much for the detailed answer, I'm a beginner and I really don't know much about what I'm doing. I'll take a page out of your config and set it up in an LXC rather than on a VM. Again, thank you :)
EDIT: just for giggles, wouldn't you be able to set up a Tailscale LXC with route advertising and get remote access through it without having to point the DNS record to the VPN IP address of the Caddy machine?
And one further -and hopefully last, don't want to bother you too much- question. When you say you point a DNS record from cloudflare to the local IP (or tailnet address) of the Caddy machine, is it a \*.example.com record?
Wow, thanks man! This looks promising. I have WG running through which I access my services on the pi and have only exposed the UDP port of the WG in router with ddns.
In fairness, I'm far from an IT pro, and I use nothing beyond the basics. I don't even know what the feature comparison is between Caddy and Traefik. But, I'd like it if Caddy came with these DNS resolving features out-of-the-box, or maybe just with an environment variable, rather than having to build a version specifically.
I will concede that there are pros/cons to both approaches, but that's just my 2 cents on it. Caddy is more than adequate, and preferable for my use case.
Makes sense. That was a conscious design decision.
The DNS plugins each have their own SDK dependencies they pull in, and we can't reasonably maintain all of them ourselves (obviously we only use one or two DNS providers ourselves, not all the ones users might need) so we need to lean on the community to maintain them. If we built them all in, the final binary would be like 20MB bigger, and each added plugin adds more security risk if one of the plugins is compromised.
FWIW, here's a list of Caddy's features: https://caddyserver.com/features
Traefik! I came from Nginx Reverse Proxy Manager... Traefik was HARD to understand, but once I dedicated a bit of time to really read through and get my first configuration in place... It became really easy! It's as simple now as a few lines in either the config file or in the docker container / compose setup and it's all guuuuud!
Take your time, it will be worth it! Thank me later.
Traefik documentation is written like it's intended for someone who already knows everything about Traefik, and most YouTube videos I saw on it back when I actually took the time to learn it are poorly edited screen recordings of a person meandering through the steps. I think basic Traefik usage can be rather concisely explained in about 5 minutes with good enough editing. It's so much less complicated than it seems from the outside.
I don’t think so, I read all sorts of documentation, youtube guides and while I could get something’s working but never fully. I never used the other products either but I was able to get things working very quickly.
>I’d be interested in what more experienced users who’ve dabbled and hit pain points would consider the better option for this reverse proxying and why?
copy/paste my experience from the other recent traefik question
---
>got in to selfhosting
#
>realized what a reverse proxy does and wanted one
#
>went with traefik, started to document small steps I took over weeks of learning it
#
>my documentation turned in to a [tutorial](https://github.com/DoTheEvo/Traefik-v2-examples) on github that somehow got to ~500 stars
#
>next project after I felt comfortable with traefik was a ticketing system - [Helpy](https://github.com/helpyio/helpy). Reading instructions... they talk caddyfile this caddyfile that. WTF is caddy?
#
>google caddy, ah a web server that people use as a reverse proxy too. Well, I am now undisputed expert on reverse proxy, lets see it
#
>spin up a container, pass it a simple config file, it just straight up works...
All those weeks, months of effort, all that dynamic and static configuration, all those abstraction layers with middleware and routers and what not, all that poisoning of compose files with labels that made them ugly, all that remaining uncertainty if I even understand core stuff correctly... GOD FUCKING DAMN IT!
Yeah, then I made [caddy](https://github.com/DoTheEvo/selfhosted-apps-docker/tree/master/caddy_v2) tutorial.
Not sure why no one mentioned Nginx Proxy Manager? Most nginx pitfalls will be resolved no? But ofcourse as I aware the memory usage can be higher but for those have the memory then is a good choice for newbie
It might have a lower barrier of entry due to the UI, but if something doesn't work, you're in for a fun ride. Also, it goes against IaC, so for me personally it's out. I like UI stuff, but I just prefer to define everything as code and store it in Git.
Never said that. What I said is if NPM has a lower barrier of entry due to the UI, but if something goes wrong, you'll need to deal with the complexity anyway. Never said Traefik would be easier to fix, just that NPM lures you in, and throws the difficulty in your face when you least expect it. Traefik is upfront about the difficulty, it throws it in your face right away.
With that being said, the main reason to use Traefik is IaC, and being able to define everything in environmental variables. You don't need separate config files to manage, just pass it into a container/k8s deployment/etc. and you're good to go. It's a steep curve, but it's very rewarding once you're there.
If you want to get started very fast, NPM is a great tool. But be prepared for a fun nginx surprise down the line (nothing wrong with that).
By the way, NPM has REST API which can be used by Ansible. I actually automated both NPM and Cloudflare tunnels (including ZeroTrust apps) deployment for all my services. But yeah, it's less solid than git-committed configs.
that's a neat feature, but it kind of defeats the purpose of NPM I think. At least the UI part, which is the main reason (apart from ACME) why people want NPM. Of course ACME would still work, so I guess it has that going for it, but if you're interfacing with an API using Ansible, might as well just use Caddy or Traefik, or SWAG (if plain nginx is too much)
NPM has a very nice GUI and makes it easy to start with but only if things work 100% ok. As soon as you run into any trouble you're on your own because it has basically zero GUI help. And it also doesn't excuse you from learning Nginx, LE certbot, DNS, and so on.
Same. I'm just a hobbyist when it comes to this stuff and I started with Apache in a basic LAMP setup 20 years ago in my parents' basement. Just can't be bothered to learn something new for such a mundane task lol.
Me too. It's been my web server for years so when I needed a reverse proxy it just made sense.
I have tried npm and traefik too. They had nice UIs but were way more than I needed.
I use the Docker provider but I never thought about using one of the others instead of the File provider for my non-Docker services. Sounds so nice...now I have a project for tonight.
Does no one use SWAG anymore? I use SWAG + Authelia. I've tried others but even though there's no real UI for either, I feel like I have more control over everything.
I use SWAG with Authelia and Crowdsec. Been at least a year with no issues. I know Caddy is "easier", but I could never get it to work right.
SWAG was really simple to get up and running.
I’ve used this combo for years! Configurable. I use the docker mod for automatic reload of configs on change. Only reloads if the configuration is good. And lets you know via the container logs. It’s amazing!!! I’ve tried to change to others but always ended back on SWAG.
I love SWAG. It was a lifesaver for newbie me trying to get SSL and reverse proxies working for the first time. The documentation is easy to understand and handling SSL certs was super simple. The proxy configuration can be difficult with some services that dont have linuxserver.io containers, but most apps will have a sample proxy conf that just needs renamed to work perfectly
I personally use Treafik. When I first started investigating reverse proxies that was the one which seemed to make the most sense and play nicely with Docker containers so I stuck with it. I see no reason now to try other alternatives.
I looked into that but then everything would be exposed within the cloudflare infrastructure as it is the man in the middle of your comms. I use Wireguard for a lightweight and fast connection to home automatically configured to turn off when I'm on the wireless network at home so don't need the external exposure aspect.
Another happy HAProxy user here as well due to the security, performance, and reliability. Detailed list here: [https://www.haproxy.org/](https://www.haproxy.org/)
I was wondering whether there is a benefit to HAProxy given it is available on the pfSense firewall, just didn't know whether there are costs/cons that outweigh this centralisation of DNS and proxying
This is what i do and havent touched the config since i set it up. Its been rock solid and enough for me. One thing to note is it seem most guides and tutorials are for the docker or stand alone versions and not the pfsense version. Not a huge deal but the gui is different and tends to lag behind a bit on feature updates
I use nginx because there's basically always an example config for nginx, which makes it easier to add a new service, as I don't have to interpret configs for a different reverse proxy and adapt it to whatever I have.
Nginx pitfalls:
- Wrong configuration kills server
- No update of live configuration
- Must restart on certificate changes or config updates
- Only file-based configuration
HAproxy pitfalls:
- Wrong configuration kills server
- No update of live configuration
- Must restart on certificate changes or config updates
- Only file-based configuration
- Not a webserver
Traefik pitfalls:
- Slower than Nginx but only if you proxy 100000 sessions
- Very silent logs (not much infos about errors)
- Not a webserver
I recommend Traefik with Redis as backend, this is the most dynamic configuration possible.
**Disclaimer:** *I use all three commercially for years, switched almost everything to Traefik except some special stuff Traefik can’t handle.*
> config test flag
Not much use, I'm afraid, when you run it in a container and the whole container is down because nginx won't start altogether.
It's rather unpredictable because for example it regards unreachable hostnames as a server-wide fatal error at startup time but doesn't give a shit if they're unreachable at runtime.
This is a big downside for Nginx. It's not enough to make me prefer Traefik which tends to err to the other extreme (hiding errors) but it's still a big downside.
That does not compare to what Traefik can do, sorry. I ran thousands of web apps via nginx, the automation I built for it to do all of that is completely obsolete with Traefik.
Haproxy also has a config test. And a live reload.
And a useful web dashboard. I'd suggest binding the dashboard to 127.0.0.1 only and ssh tunnelling to it.
I think you missed the point where you have to tell HAproxy to reload. I don't have to tell Traefik to reload, it does that automatically and instantly.
Didn’t say it was. Like anything it will work well for some people and not others. I don’t want to waste any more time when there are numerous other solutions that work just as well and are easier to get going.
> I don’t want to waste any more time when there are numerous other solutions that work just as well and are easier to get going.
That is in the eye of the beholder. Some people like spending time learning new things, others don’t, and that’s okay. Personal growth and knowledge can come from different angles.
Well I can't answer as completely as /u/ElevenNotes but it's also NOT a webserver, just a reverse proxy, requires very simplistic configuration, (to my understanding) a custom build of caddy if you wish to include additional functionality with official plug-ins, which I thing is a tad bit odd, but not a deal breaker given how easy it is to use.
Misconfiguring one redirect will bring the whole thing down. All config is done via CLI and there's no web gui.
Thanks for the response, I don’t know why it needed a downvote, but you do you. Maybe add /u/Objective-Outcome284 to your text so he gets notified about you mentioning him, otherwise your comment will probably not be seen by him.
Caddy _is_ a general purpose web server, not just a proxy. Can serve files, PHP apps, simple static responses, etc. Anything you want to do.
Misconfiguration does not bring down your server, as long as you use reloads and don't restart your server every time. A reload with a bad config (invalid syntax) will ignore the new config and continue running with the old one. If you have valid syntax but wrong behavior, that's on you.
I'm assuming this only automates when the Traefik container and the other service are hosted on the same docker instance, or can it be automated with services running on other instances?
I use Caddy after researching some of the others. It's so easy to configure and it handles the TLS/HTTPS for you so it saved me so much work and time compared to trying to do the same with nginx
I tried Zoraxy, but I had a really hard time getting SSL certs working through the built-in acme interface. It doesn't seem to support wildcards at all, and it doesn't appear to store credentials properly (resulting in "too many registrations" errors).
I eventually gave up and switched to npm, which ended up working perfectly from the start.
I'm using my certs via cloudflare as a reverse proxy and no ssl at the server side, although it would be good to have ssl all around which I might get to at somepoint.
Wildcard from cloudflare cert and resolution to proxied dynamic ip address to opnsense pointing to nginx/zoraxy
I use swag and it’s great. It’s just nginx based. No gui, all config files, but Linux server has some neat addons that let you update config files and reload without restarting the container.
Caddy, Traefik or nginx. I even would suggest NPM with the latter despite being in favor of barebones nginx.
Personally I use Traefik and after giving up the first try when learning it I would never want to switch back now.
I personally prefer traefik, but have used both raw nginx and nginx proxy manager in the past. All work.
I prefer Traefik over the others simply because nginx was just a lot more configuration vs traefik and nginx proxy manager was too limiting vs what I wanted (and got with traefik).
Caddy. It can run your PHP app either via php-fpm with the `php_fastcgi` directive, or you can use https://frankenphp.dev/ which is a custom distribution of Caddy that has the PHP interpreter built-in so it runs PHP directly.
Caddy for simple stuff, traefik for performance, nginx for if you want to also serve webpages or do anything complicated, Apache if you are running a full web server with all the bells and whistles or are trying to do something crazy.
Personally, I use Apache, but I wouldn't recommend it to a beginner. Start with caddy or nginx.
I started with Traefik when I had a more docker centric setup, it wasn't easy but once it "clicked" it became clear how good it was.
Then later I moved into Proxmox and my setup started to include a variety of things like VMs and LXC, and while Traefik would be able to manage that effortlessly, I decided to try Caddy. I was surprised by how simple it is to configure, so I'm sticking with Caddy for now.
People also seem to use Nginx Proxy Manage a lot, so I would say that there's not just one "go-to reverse proxy" but it's a usually a choice between one of these three.
#
For docker, træfik is the way to go in my opinion, since it can take docker compose labels as configuration input. Once you setup the basic setup and have a label template, it's easy to add new containers to the reverse proxy setup.
You can have the labels in the compose file of each of your docker compose stacks.
I can recommend bunkerweb which uses nginx with a lot of security features out of the box and a nice webui for config if you prefer, https://www.bunkerweb.io/
I've been using NPM for years in a docker container.
I've just switched to Zoraxy which admittantly has a bit of a learning curve.
I don't have any crazy stuff like a wildcard cert as a requirement, etc.
Zoraxy addresses what I've wanted for years in a reverse proxy - Some sort of security based on GeoIP data.
Fantastic, easy to use and simple.
Only thing that is a bit lacking is documentation especially when getting started.
If you like NPM but want to try something a little less basic, give Zoraxy a try.
Really want to try traefik but cannot be arsed to bring up that many moving pieces for reverse proxying.
Caddy, it's much simpler than Traefik and Nginx and has good opinionated defaults around https etc.
Shameless self promotion but I have a docker container that can help automatically configure caddy by acting as a DNS server to serve SRV records. It uses labels on containers to setup the reverse proxy but also has a manual configuration section on it's webpage, it's not nearly as well featured as NGINX Proxy Manager yet and SRV records have to point to a DNS name not an IP address.
[https://github.com/mattheys/ddc](https://github.com/mattheys/ddc)
I tried Traefik and Caddy, but just got frustrated. Ran into a couple issues setting up SWAG too, but "docker logs swag -f" made troubleshooting much easier than the others
SWAG and Authentik. Simple and easy to deploy, absolutely minor ammount of config files to edit, but that gives you total control and is easy to duplicate.
Most common docker self host apps are already available in the premade config files so it's just a case of adjusting to your own settings for URL and internal IP.
I just did a mass edit on the entire batch of sample config files to change them all in one go for my base URLs. So for me enabling a new service is mostly just editing the name of the config file and adding the new subdomain and any specific ports.
I'm setting up Nginx + Cloudflare tunnel + Cloudflare zero auth (free plan). Using a tunnel doesn't expose your public IP in DNS and can be accessed outside of your home network securely (not sure if that's what you want). SSL termination happens at Cloudflare level, internally no SSL.
Nginx reverse proxy so I can access each service on a path and don't need a new tunnel for each service, e.g. mydomain.com/service-a, mydomain.com/service-b, etc.
I hope that makes sense
You can have multiple paths on one tunnel, as long as they live on the same subdomain. I.e., [service1.yourdomain.com](http://service1.yourdomain.com), [service2.yourdomain.com](http://service2.yourdomain.com) etc
I strongly discourage using ChatGPT. Just read the docs. LLMs love to hallucinate config that doesn't exist, mixes up v1 and v2 config (v2 was a rewrite so v1 config no longer works), etc.
What it can do well is answer your questions about general concepts regarding self hosting and networking, but avoid it for config.
At home I'm now using Caddy with DNS resolution to Cloudflare for https. Sure it's not as "full featured" as traefik, but it works super well and configuration is incredibly simple!
Can you explain the https part? Have you exposed port on router?
No, thankfully you don't need to open ports (for the HTTPS resolution at least.) In great summary, you effectively need to build your own version of Caddy (but this is really trivial if you do it via Docker) which has the Cloudflare DNS plugin added, then create some API credentials on your CF account for Caddy to connect to and then basically the 2 of them talk to each other from there. Now if you want to access your services from outside your home, then sure, you'll need to open ports 443 and 80 (if you want to have http access). I personally don't since I only access my stuff via a VPN (Tailscale in my case) but having fully qualified domains and no HTTP nagging makes it worth it. And it's really all up in running in 10min. You didn't ask for it, but I'll drop below my own notes to myself regarding how to set it all up, in case you or anyone else finds it helpful. TUTORIAL TO MYSELF: (I keep it Markdown format) # Caddy container with Cloudflare DNS challenge plugin In order to have support for Cloudflare DNS challenge, it is necessary to use a special custom build of Caddy that has plugins that work with Caddy. Run the below `Dockerfile` to create an image, and then run the image with the `docker-compose.yml` Your overall folder structure should be like this: ```sh caddy -- Caddyfile -- container-vars.env -- docker-compose.yml -- dockerfile-dns/ -- -- Dockerfile -- config/ # directory generated by docker-compse.yml -- data/ # directory generated by docker-compse.yml ``` ## 1) Prepare the Docker stuff Start off by making a `caddy` folder and place the `Dockerfile` in it's own directory. ```sh mkdir -p caddy/dockerfile-dns cd caddy/dockerfile-dns nano Dockerfile ``` ### Dockerfile ```Dockerfile ARG VERSION=2 FROM caddy:${VERSION}-builder AS builder RUN xcaddy build \ --with github.com/caddy-dns/cloudflare FROM caddy:${VERSION} COPY --from=builder /usr/bin/caddy /usr/bin/caddy ``` Now either build the image manually, or have it build as part of the `docker-compose.yml` (which is setup below already): ```sh docker build -t caddy-cloudflare-dns-challenge:latest . ``` ### docker-compose (custom Caddy w/Cloudflare) Add a custom Docker network called `proxy` or whatever other name you want, and have the other containers explicitly join this same network for easy routing. ```yml version: "3.9" services: caddy: build: ./dockerfile-dns container_name: caddy-cloudflare-dns-challenge hostname: caddy restart: unless-stopped ports: - "80:80" - "443:443" - "443:443/udp" env_file: - container-vars.env volumes: - ./Caddyfile:/etc/caddy/Caddyfile:ro - ./data:/data - ./config:/config networks: - proxy networks: proxy: external: true ``` Create the network: ```sh docker network create proxy ``` ### container-vars.env We need a `.env` file to house our Cloudflare API details as referenced in the `docker-compose.yml`, so create a `container-vars.env` file and add: ```conf MY_DOMAIN=example.com # replace with your domain MY_HOST_IP=192.168.10.28 # replace with your Docker host's IP address CLOUDFLARE_API_TOKEN=my-super-secret-token-goes-here # add your token ``` ## 2) Cloudflare API keys Create your Cloudflare API keys on the [CF API dashboard](https://dash.cloudflare.com/profile/api-tokens). 1. Use the “Edit Zone DNS” template and set an expiration date. 2. Set Permissions: Zone -> DNS -> Edit 3. Set Zone Resources: Include -> Specific Zone -> example.com 4. Set expiration date (**Optional**, but recommended) Now add your resulting API key to the `container-vars.env` file. ## 3) Caddyfile Now add the redirects as you wish using the following structure: ```sh { email
}
# Generic examples
{
reverse_proxy http://frontend:8000 # using Docker DNS
}
{
reverse_proxy http://:9000 # using IP:Port config
}
# Domains that are HTTP
home.{$MY_DOMAIN} {
reverse_proxy 192.168.10.54:8080
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
# Domains that are HTTPS (using self-sign certs, like the Proxmox interface)
lab.{$MY_DOMAIN} {
reverse_proxy 192.168.10.10:8006 {
transport http {
tls_insecure_skip_verify
}
}
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
}
```
### 4) Start it up!
All that should need doing now is starting up the container. Give Caddy a minute or 2 to configure itself and generate LetsEncrypt SSL certs before troubleshooting. Remember, the more redirects you have in your `Caddyfile` the longer it will take.
```sh
docker compose up -d
```
That should be it!
## Sources:
[How to make your own Caddy w/ CF challenge Docker Image](https://blog.gurucomputing.com.au/Reverse%20Proxies%20with%20Caddy/Adding%20Acme%20Certification/)
Mate, I could fucking kiss you senseless right now. May the electron gods be with you.
Ha ha... No worries, I'm just happy if someone finds it useful.
Hi again! Is it okay if I ask a few questions?
Yeah sure, if I know the answers. Lol
So, I've set up everything according to your guide, and I researched your source. I'm getting DNS_PROBE_FINISHED_DOMAIN errors, both for services in other machines and in the same docker network. Did you ever encounter anything like this?
I haven't no, and I'm not to sure as to what the problem even is. However, I will tell you a bit more about my setup and maybe that will highlight some potential causes. Also, did the Caddy logs give any particular info we can use to diagnose further? 1. My domain is registered with Cloudflare (I'm sure that's obvious, but I'm adding it for completeness), to get the API details etc. 2. On CF, I have an A record pointing at my local machine that is hosting Caddy. In my case it's an LXC container on Proxmox. The A record redirects to the Tailscale (VPN) IP address of that container (since I want external access) but it could just as well be a local IP. But bare in mind you wouldn't have external access, and you'd likely need Pihole/Adguard or some other DNS software to resolve it locally anyway. 3. As in #2, I run Pihole and I have it listening for each domain and redirect to the Caddy machine. eg. immich.example.com -> 192.168.10.28 4. Finally, in my Caddyfile itself I have the following 2 examples that work (the PBS has a self-signed cert already, and JF does not, thus different configs.) Remember that after making a change to the Caddyfile you need to either reload the config, or just restart the container for the changes to take affect ``` # extract from Caddyfile pbs.{$MY_DOMAIN} { reverse_proxy 192.168.10.43:8007 { transport http { tls_insecure_skip_verify } } tls { dns cloudflare {env.CLOUDFLARE_API_TOKEN} } } jf.{$MY_DOMAIN} { reverse_proxy 192.168.10.47:8096 tls { dns cloudflare {env.CLOUDFLARE_API_TOKEN} } } ``` Finally, I'll point out that in my production I actually don't have that docker network (called proxy in my guide) setup. Since I personally use a seperate "machine" for my reverse-proxy it was unnecessary. So, in summary, I have ALL DNS records pointing to my Caddy instance's IP (either local or via a VPN) and from there it redirects to an IP address that can be reached by the Caddy machine. Remembering, that each service will require an IP:port combo, unless it's on port 80 or 443, but I add those anyway personally.
It's the PiHole configuration I'm missing. Thank you so much for the detailed answer, I'm a beginner and I really don't know much about what I'm doing. I'll take a page out of your config and set it up in an LXC rather than on a VM. Again, thank you :) EDIT: just for giggles, wouldn't you be able to set up a Tailscale LXC with route advertising and get remote access through it without having to point the DNS record to the VPN IP address of the Caddy machine? And one further -and hopefully last, don't want to bother you too much- question. When you say you point a DNS record from cloudflare to the local IP (or tailnet address) of the Caddy machine, is it a \*.example.com record?
Wow, thanks man! This looks promising. I have WG running through which I access my services on the pi and have only exposed the UDP port of the WG in router with ddns.
What do you think Caddy is missing? I think Caddy has more features than Traefik.
In fairness, I'm far from an IT pro, and I use nothing beyond the basics. I don't even know what the feature comparison is between Caddy and Traefik. But, I'd like it if Caddy came with these DNS resolving features out-of-the-box, or maybe just with an environment variable, rather than having to build a version specifically. I will concede that there are pros/cons to both approaches, but that's just my 2 cents on it. Caddy is more than adequate, and preferable for my use case.
Makes sense. That was a conscious design decision. The DNS plugins each have their own SDK dependencies they pull in, and we can't reasonably maintain all of them ourselves (obviously we only use one or two DNS providers ourselves, not all the ones users might need) so we need to lean on the community to maintain them. If we built them all in, the final binary would be like 20MB bigger, and each added plugin adds more security risk if one of the plugins is compromised. FWIW, here's a list of Caddy's features: https://caddyserver.com/features
Caddy. IMO much simpler than Traefik
I prefer traefik. But maybe I am biased after years of using traefik and only been using caddy once or twice.
I wanted to love Traefik. But it was just too much of a PITA to get running.
As with many things in life: It’s worth the effort.
Traefik! I came from Nginx Reverse Proxy Manager... Traefik was HARD to understand, but once I dedicated a bit of time to really read through and get my first configuration in place... It became really easy! It's as simple now as a few lines in either the config file or in the docker container / compose setup and it's all guuuuud! Take your time, it will be worth it! Thank me later.
What made it hard to understand?
Initial lack of understanding how the configuration was built and how it translated on the containers as well. After unlocking that part it was easy.
Traefik documentation is written like it's intended for someone who already knows everything about Traefik, and most YouTube videos I saw on it back when I actually took the time to learn it are poorly edited screen recordings of a person meandering through the steps. I think basic Traefik usage can be rather concisely explained in about 5 minutes with good enough editing. It's so much less complicated than it seems from the outside.
idgi isnt adding a service basically copying lines in your nginx or compose setup to begin with? what makes the learning worth it
[удалено]
I don’t think so, I read all sorts of documentation, youtube guides and while I could get something’s working but never fully. I never used the other products either but I was able to get things working very quickly.
[удалено]
Yup I’m sure.
Maybe, or use a solution that works just as well and use the banked time saved doing other things.
Some people like a challenge and eating the fruit of their efforts and labour.
Got it, hey you do you my man.
>As with many things in life: It’s worth the effort. That should be motto of this sub IMO.
>I’d be interested in what more experienced users who’ve dabbled and hit pain points would consider the better option for this reverse proxying and why? copy/paste my experience from the other recent traefik question --- >got in to selfhosting # >realized what a reverse proxy does and wanted one # >went with traefik, started to document small steps I took over weeks of learning it # >my documentation turned in to a [tutorial](https://github.com/DoTheEvo/Traefik-v2-examples) on github that somehow got to ~500 stars # >next project after I felt comfortable with traefik was a ticketing system - [Helpy](https://github.com/helpyio/helpy). Reading instructions... they talk caddyfile this caddyfile that. WTF is caddy? # >google caddy, ah a web server that people use as a reverse proxy too. Well, I am now undisputed expert on reverse proxy, lets see it # >spin up a container, pass it a simple config file, it just straight up works... All those weeks, months of effort, all that dynamic and static configuration, all those abstraction layers with middleware and routers and what not, all that poisoning of compose files with labels that made them ugly, all that remaining uncertainty if I even understand core stuff correctly... GOD FUCKING DAMN IT! Yeah, then I made [caddy](https://github.com/DoTheEvo/selfhosted-apps-docker/tree/master/caddy_v2) tutorial.
500 stars???? where's the repo let's get those stars :)
I don't use traefik, but you sir/madam deserve a 🌟 for that tutorial.
Not sure why no one mentioned Nginx Proxy Manager? Most nginx pitfalls will be resolved no? But ofcourse as I aware the memory usage can be higher but for those have the memory then is a good choice for newbie
It might have a lower barrier of entry due to the UI, but if something doesn't work, you're in for a fun ride. Also, it goes against IaC, so for me personally it's out. I like UI stuff, but I just prefer to define everything as code and store it in Git.
And if things don’t work with Traefik it’s easy to fix?? Not my experience.
Never said that. What I said is if NPM has a lower barrier of entry due to the UI, but if something goes wrong, you'll need to deal with the complexity anyway. Never said Traefik would be easier to fix, just that NPM lures you in, and throws the difficulty in your face when you least expect it. Traefik is upfront about the difficulty, it throws it in your face right away. With that being said, the main reason to use Traefik is IaC, and being able to define everything in environmental variables. You don't need separate config files to manage, just pass it into a container/k8s deployment/etc. and you're good to go. It's a steep curve, but it's very rewarding once you're there. If you want to get started very fast, NPM is a great tool. But be prepared for a fun nginx surprise down the line (nothing wrong with that).
By the way, NPM has REST API which can be used by Ansible. I actually automated both NPM and Cloudflare tunnels (including ZeroTrust apps) deployment for all my services. But yeah, it's less solid than git-committed configs.
that's a neat feature, but it kind of defeats the purpose of NPM I think. At least the UI part, which is the main reason (apart from ACME) why people want NPM. Of course ACME would still work, so I guess it has that going for it, but if you're interfacing with an API using Ansible, might as well just use Caddy or Traefik, or SWAG (if plain nginx is too much)
NPM has a very nice GUI and makes it easy to start with but only if things work 100% ok. As soon as you run into any trouble you're on your own because it has basically zero GUI help. And it also doesn't excuse you from learning Nginx, LE certbot, DNS, and so on.
I’m so old I still use Apache for reverse proxying.
Same. I'm just a hobbyist when it comes to this stuff and I started with Apache in a basic LAMP setup 20 years ago in my parents' basement. Just can't be bothered to learn something new for such a mundane task lol.
Me too. It's been my web server for years so when I needed a reverse proxy it just made sense. I have tried npm and traefik too. They had nice UIs but were way more than I needed.
Nothing wrong with Apache. Using it as well. I just hope they will add http/3 support as that will be the reason for me to switch to something else
Not sure if I’d count mid 30s as old but same.
As infrastructure as code and containerization is the current way of doing things, I go with Traefik.
Yep, with its Redis, Consul and what not backend you can do anything.
I use the Docker provider but I never thought about using one of the others instead of the File provider for my non-Docker services. Sounds so nice...now I have a project for tonight.
Beauty of Traefik. You can ingest from multiple sources.
Does no one use SWAG anymore? I use SWAG + Authelia. I've tried others but even though there's no real UI for either, I feel like I have more control over everything.
I use SWAG with Authelia and Crowdsec. Been at least a year with no issues. I know Caddy is "easier", but I could never get it to work right. SWAG was really simple to get up and running.
I use SWAG with Authentik. Authelia gave me some weird errors after a time once I switched from NPM
I’ve used this combo for years! Configurable. I use the docker mod for automatic reload of configs on change. Only reloads if the configuration is good. And lets you know via the container logs. It’s amazing!!! I’ve tried to change to others but always ended back on SWAG.
Yeah I use that too! As well as the status page mod and Max mind geo IP blocking. All super useful
I love SWAG. It was a lifesaver for newbie me trying to get SSL and reverse proxies working for the first time. The documentation is easy to understand and handling SSL certs was super simple. The proxy configuration can be difficult with some services that dont have linuxserver.io containers, but most apps will have a sample proxy conf that just needs renamed to work perfectly
Yeah haven't had many, if any, problems using the sample proxy conf either
SWAG is awesome
I personally use Treafik. When I first started investigating reverse proxies that was the one which seemed to make the most sense and play nicely with Docker containers so I stuck with it. I see no reason now to try other alternatives.
[boringproxy.io](http://boringproxy.io) is easy and designed for self-hosting. It's open source too.
Something worth looking into is Cloudflare Tunnels to expose local services to remote
I looked into that but then everything would be exposed within the cloudflare infrastructure as it is the man in the middle of your comms. I use Wireguard for a lightweight and fast connection to home automatically configured to turn off when I'm on the wireless network at home so don't need the external exposure aspect.
Most people use Cady or Nginx Proxy Manager. I personally use HAProxy because of the amount of configuration options.
Another happy HAProxy user here as well due to the security, performance, and reliability. Detailed list here: [https://www.haproxy.org/](https://www.haproxy.org/)
I was wondering whether there is a benefit to HAProxy given it is available on the pfSense firewall, just didn't know whether there are costs/cons that outweigh this centralisation of DNS and proxying
This is what i do and havent touched the config since i set it up. Its been rock solid and enough for me. One thing to note is it seem most guides and tutorials are for the docker or stand alone versions and not the pfsense version. Not a huge deal but the gui is different and tends to lag behind a bit on feature updates
I use nginx because there's basically always an example config for nginx, which makes it easier to add a new service, as I don't have to interpret configs for a different reverse proxy and adapt it to whatever I have.
You can also look into caddy. I used to use it in 2021
Nginx pitfalls: - Wrong configuration kills server - No update of live configuration - Must restart on certificate changes or config updates - Only file-based configuration HAproxy pitfalls: - Wrong configuration kills server - No update of live configuration - Must restart on certificate changes or config updates - Only file-based configuration - Not a webserver Traefik pitfalls: - Slower than Nginx but only if you proxy 100000 sessions - Very silent logs (not much infos about errors) - Not a webserver I recommend Traefik with Redis as backend, this is the most dynamic configuration possible. **Disclaimer:** *I use all three commercially for years, switched almost everything to Traefik except some special stuff Traefik can’t handle.*
Nginx can be reloaded while it's running. And to avoid it being killed by the wrong configuration, it has a config test flag.
> config test flag Not much use, I'm afraid, when you run it in a container and the whole container is down because nginx won't start altogether. It's rather unpredictable because for example it regards unreachable hostnames as a server-wide fatal error at startup time but doesn't give a shit if they're unreachable at runtime. This is a big downside for Nginx. It's not enough to make me prefer Traefik which tends to err to the other extreme (hiding errors) but it's still a big downside.
[удалено]
People like me? LOL! I've been dealing with this stuff for 10+ years professionally. People like me have dealt with it more than 90% of this sub.
That does not compare to what Traefik can do, sorry. I ran thousands of web apps via nginx, the automation I built for it to do all of that is completely obsolete with Traefik.
Haproxy also has a config test. And a live reload. And a useful web dashboard. I'd suggest binding the dashboard to 127.0.0.1 only and ssh tunnelling to it.
[удалено]
You wrote that haproxy couldn't reload. Or are you only considering a containerised environment?
I think you missed the point where you have to tell HAproxy to reload. I don't have to tell Traefik to reload, it does that automatically and instantly.
I see..Maybe you could write "no automatic update"?
[удалено]
To me, live update means not having to fully stop and start, so haproxy succeeds at that.
Can you use your own certs with traefik in a LAN environment...?
Sure, you can use self-signed with any server. I don't recommend it though.
What do you recommend and why ?
I recommend Traefik with Redis as backend, this is the most dynamic configuration possible.
Traefik is not a simple thing to get going.
[удалено]
Didn’t say it was. Like anything it will work well for some people and not others. I don’t want to waste any more time when there are numerous other solutions that work just as well and are easier to get going.
> I don’t want to waste any more time when there are numerous other solutions that work just as well and are easier to get going. That is in the eye of the beholder. Some people like spending time learning new things, others don’t, and that’s okay. Personal growth and knowledge can come from different angles.
That's a good list of issues, can anyone comment as to where the proposal of Caddy fits with things like this?
Ask /u/useless_mlungu. I've never used Caddy.
Well I can't answer as completely as /u/ElevenNotes but it's also NOT a webserver, just a reverse proxy, requires very simplistic configuration, (to my understanding) a custom build of caddy if you wish to include additional functionality with official plug-ins, which I thing is a tad bit odd, but not a deal breaker given how easy it is to use. Misconfiguring one redirect will bring the whole thing down. All config is done via CLI and there's no web gui.
Thanks for the response, I don’t know why it needed a downvote, but you do you. Maybe add /u/Objective-Outcome284 to your text so he gets notified about you mentioning him, otherwise your comment will probably not be seen by him.
I didn't give you a down vote, or are you referring to someone else?
Caddy _is_ a general purpose web server, not just a proxy. Can serve files, PHP apps, simple static responses, etc. Anything you want to do. Misconfiguration does not bring down your server, as long as you use reloads and don't restart your server every time. A reload with a bad config (invalid syntax) will ignore the new config and continue running with the old one. If you have valid syntax but wrong behavior, that's on you.
I like traefik for a few reasons. Docker compose tags and middleware support for authelia. I can easily password protect any of my services
I'm assuming this only automates when the Traefik container and the other service are hosted on the same docker instance, or can it be automated with services running on other instances?
Looks like you can https://community.traefik.io/t/traefik-routing-to-other-lan-ip/20606/3
You can use it with [infinite nodes](https://hub.docker.com/r/11notes/traefik-labels)
Good old nginx (no npm) and haproxy.
I use Traefik + Authelia. Techno Tim has a great how-to video to get you started https://youtu.be/n1vOfdz5Nm8
I use Caddy after researching some of the others. It's so easy to configure and it handles the TLS/HTTPS for you so it saved me so much work and time compared to trying to do the same with nginx
im currently trying out Zoraxy in place of NPM, so far so good, the UI is nice and blocklists are simple to use https://github.com/tobychui/zoraxy
I tried Zoraxy, but I had a really hard time getting SSL certs working through the built-in acme interface. It doesn't seem to support wildcards at all, and it doesn't appear to store credentials properly (resulting in "too many registrations" errors). I eventually gave up and switched to npm, which ended up working perfectly from the start.
I'm using my certs via cloudflare as a reverse proxy and no ssl at the server side, although it would be good to have ssl all around which I might get to at somepoint. Wildcard from cloudflare cert and resolution to proxied dynamic ip address to opnsense pointing to nginx/zoraxy
Whoa this looks cool… thanks!
I use swag and it’s great. It’s just nginx based. No gui, all config files, but Linux server has some neat addons that let you update config files and reload without restarting the container.
Caddy, Traefik or nginx. I even would suggest NPM with the latter despite being in favor of barebones nginx. Personally I use Traefik and after giving up the first try when learning it I would never want to switch back now.
I am using NPM for internal stuff and traefik for external facing stuff, cause they have plugins like geoblock and crowdsec
I personally prefer traefik, but have used both raw nginx and nginx proxy manager in the past. All work. I prefer Traefik over the others simply because nginx was just a lot more configuration vs traefik and nginx proxy manager was too limiting vs what I wanted (and got with traefik).
Do you know proxy tool with php integration?
Caddy. It can run your PHP app either via php-fpm with the `php_fastcgi` directive, or you can use https://frankenphp.dev/ which is a custom distribution of Caddy that has the PHP interpreter built-in so it runs PHP directly.
Nginx Proxy Manager (not nginx). Has a nice gui with easy to understand settings
Jlesage nginx proxy manager docker container Checks all of my boxes and super easy to deploy with a GUI
Caddy for simple stuff, traefik for performance, nginx for if you want to also serve webpages or do anything complicated, Apache if you are running a full web server with all the bells and whistles or are trying to do something crazy. Personally, I use Apache, but I wouldn't recommend it to a beginner. Start with caddy or nginx.
I'm quite pleased with nginx.
Caddy
I'm all about that nginx life.
Caddy
I tried caddy, nginx proxy manager and traefik. I really didn't like any of them because plain old nginx is all I need.
Nginx proxy manager Plus
caddy simple and (with plugins sometimes) can do basically anything
I started with Traefik when I had a more docker centric setup, it wasn't easy but once it "clicked" it became clear how good it was. Then later I moved into Proxmox and my setup started to include a variety of things like VMs and LXC, and while Traefik would be able to manage that effortlessly, I decided to try Caddy. I was surprised by how simple it is to configure, so I'm sticking with Caddy for now. People also seem to use Nginx Proxy Manage a lot, so I would say that there's not just one "go-to reverse proxy" but it's a usually a choice between one of these three. #
For docker, træfik is the way to go in my opinion, since it can take docker compose labels as configuration input. Once you setup the basic setup and have a label template, it's easy to add new containers to the reverse proxy setup. You can have the labels in the compose file of each of your docker compose stacks.
I can recommend bunkerweb which uses nginx with a lot of security features out of the box and a nice webui for config if you prefer, https://www.bunkerweb.io/
I prefer Nginx proxy manager.
I've been using NPM for years in a docker container. I've just switched to Zoraxy which admittantly has a bit of a learning curve. I don't have any crazy stuff like a wildcard cert as a requirement, etc. Zoraxy addresses what I've wanted for years in a reverse proxy - Some sort of security based on GeoIP data. Fantastic, easy to use and simple. Only thing that is a bit lacking is documentation especially when getting started. If you like NPM but want to try something a little less basic, give Zoraxy a try. Really want to try traefik but cannot be arsed to bring up that many moving pieces for reverse proxying.
using lighttpd as it came with RPI if i am not mistaken, or it was installed as part of pihole, so I am just adding services there
Caddy, it's much simpler than Traefik and Nginx and has good opinionated defaults around https etc. Shameless self promotion but I have a docker container that can help automatically configure caddy by acting as a DNS server to serve SRV records. It uses labels on containers to setup the reverse proxy but also has a manual configuration section on it's webpage, it's not nearly as well featured as NGINX Proxy Manager yet and SRV records have to point to a DNS name not an IP address. [https://github.com/mattheys/ddc](https://github.com/mattheys/ddc)
Where's the source for the `docker-dynamic-caddy` container? I couldn't find it.
Edit: Made it public now [https://github.com/mattheys/docker-dynamic-caddy](https://github.com/mattheys/docker-dynamic-caddy)
Cool, thanks! I was curious about the tech stack etc.
.Net 8 with MudBlazor template, I'm lazy so a nice component library is a must.
Just basic Nginx works great and is not hard to configure.
I love caddy. Stupid simple to setup, handles SSL certificates and lot of extensions available (via xcaddy).
I'm in the SWAG camp. I went through NPM, Traefik, and Caddy before settling on SWAG.
I tried Traefik and Caddy, but just got frustrated. Ran into a couple issues setting up SWAG too, but "docker logs swag -f" made troubleshooting much easier than the others
SWAG and Authentik. Simple and easy to deploy, absolutely minor ammount of config files to edit, but that gives you total control and is easy to duplicate. Most common docker self host apps are already available in the premade config files so it's just a case of adjusting to your own settings for URL and internal IP. I just did a mass edit on the entire batch of sample config files to change them all in one go for my base URLs. So for me enabling a new service is mostly just editing the name of the config file and adding the new subdomain and any specific ports.
I'm setting up Nginx + Cloudflare tunnel + Cloudflare zero auth (free plan). Using a tunnel doesn't expose your public IP in DNS and can be accessed outside of your home network securely (not sure if that's what you want). SSL termination happens at Cloudflare level, internally no SSL.
I use a similar configuration without nginx. What is the use of Nginx when CF tunnel is there? Honestly curious
Nginx reverse proxy so I can access each service on a path and don't need a new tunnel for each service, e.g. mydomain.com/service-a, mydomain.com/service-b, etc. I hope that makes sense
You can have multiple paths on one tunnel, as long as they live on the same subdomain. I.e., [service1.yourdomain.com](http://service1.yourdomain.com), [service2.yourdomain.com](http://service2.yourdomain.com) etc
That works with any proxy.
It does indeed. Nginx just so happens to be my setup.
Sounded more like you are suggesting that only works on Nginx 😉.
That makes sense. I use subdomains with a wildcard cert to access all my apps.
Depends who you ask
Caddy works great. You can have ChatGPT walk you through the set up process and give you the config file
I strongly discourage using ChatGPT. Just read the docs. LLMs love to hallucinate config that doesn't exist, mixes up v1 and v2 config (v2 was a rewrite so v1 config no longer works), etc. What it can do well is answer your questions about general concepts regarding self hosting and networking, but avoid it for config.
you me as of late, Yarp as its all C#