Made caddy v2 reverse proxy docker tutorial, critique?

Showcase
1

The way I learn shit is mostly by try and see and then try to understand by making changes and reading documentation once I got some rough idea about that stuff.

So… there might be some shit I got wrong even when it works in my tests. That goes for docker or all other related concepts too.

Like for example the way you are suppose to point to docker containers, or should there be something about headers forwarding and if its something to be concerned about in general use?

Or if its normal that if I exec in to caddy contaienr, I find certificates in /root/.local/share/caddy even if I googled out other docker-compose files are concerned only with /root/.caddy

The guide is mostly aimed at selfhosting, homelab stuff… will submit to reddit at some point.

Funny thing is. I did traefik guide few weeks back, and literally the moment I decided I am finally done and know enough and move on to actually put it to use… the first service I started to play with Helpy - opensource ticketing system, had one of the first instructions “edit Caddyfile”… I am like wtf is caddyfile… google… and fuck… here we go again… jumping ship for shiny new thing.
But at least after exposure to traefik I am now able to appreciate caddy much more.

2

Hi @DoTheEvo, welcome to the Caddy community!

We’re always pretty happy to see people put together guides.

Got only a few pointers for you:

  1. GitHub - DoTheEvo/Caddy-v2-examples
    • These proxies can be one-liners, e.g.: reverse_proxy 10.0.19.5:80
    • This change can be repeated serveral times throughout the guide
  1. GitHub - DoTheEvo/Caddy-v2-examples
    • The official Docker image caddy/caddy now uses the /config and /data directories for storage that should be persisted. As of writing this, it looks like the Docker Hub page hasn’t updated the readme, but the Github for the project has: GitHub - caddyserver/caddy-docker: Source for the official Caddy v2 Docker Image
    • You’ll want both directories - /data contains all the TLS/ACME assets and /config contains the current configuration for persisting through restarts. You will ALSO want to volume mount your actual static site files, if you serve any.

That’s it for the guide. As for this:

Nope. Shouldn’t be anything in there as of the latest container versions.

The rest looks pretty straightforward and accurate.

Personally I’m glad to hear you’re jumping to the shiny new thing and that the shiny new thing is Caddy v2 :smiley:

3 Likes
3

Thnx for the info.

While one liners look nice and clean, I feel the pre-prepared look for some other directives is good, and its not too crowded.

I noticed the /data change yesterday and was trying to get nextcloud working. Now when you mentioned it I can see that I can inspect container and see XDG_DATA_HOME and XDG_CONFIG_HOME and their values.

Updated it and will see what pops up as I actually will try to get going stuff I want to get going… nextcloud, bookstack, portainer, bitwarden_rs, helpy or zammad,…

1 Like
4 
reverse_proxy {
        to nginx:80
    }

I am bit surprised about the to. Is this required or official caddy syntax? I found this nowhere in the docs.

5

No, it’s allowed but is a matter of preference. It’s mostly intended for if you have a lot of backends.

That is equivalent to reverse_proxy nginx:80.

1 Like
6

Thanks, good to know. If going the verbose route for the tutorial I would also consider including a matcher?

7

I mean, the given reason for being verbose is so that the braces and structure are all there ready for later should other break out options be required.

If you want to break out a match-all so that you can have the structure there to refine later on, you could. It’d just be an advanced matcher with only path *, probably.

While I’d never bother, it’ll function just fine.

8

This topic was automatically closed after 14 days. New replies are no longer allowed.