Here’s how I use Comentario with Caddy.

Comentario docker-compose.yml file:

services:
  comentario-db:
    image: postgres:17-alpine
    container_name: comentario-db
    environment:
      POSTGRES_DB: comentario
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - ./db:/var/lib/postgresql/data
    restart: always
    networks:
      - caddy

  comentario:
    image: registry.gitlab.com/comentario/comentario
    container_name: comentario
    environment:
      BASE_URL: https://comments.yourdomain.com/
      SECRETS_FILE: "/secrets.yaml"
    volumes:
      - ./secrets.yaml:/secrets.yaml:ro
    restart: always
    depends_on:
      - comentario-db
    networks:
      - caddy
networks:
  caddy:
    external: true

Here’s the Caddyfile entry:

I use Caddy on my VPS because:

• It’s simple to set up. No UI, just a config file.
• It’s perfectly happy to run in a Docker container. I try to run everything as a Docker container. Makes things super simple to set up and update.
• It automatically obtains SSL certificates from Let’s Encrypt. All the other popular open source reverse proxies do this too, nevertheless it’s a nice feature.

Docker Compose Setup

1. Create a Docker network to make mapping applications easier (see the Caddyfile explanation below). You’ll want to use this same network in any application hosted in Docker containers that use Caddy.

The base Caddy Docker image is intentionally lean—around 50MB—to avoid bundling unnecessary components. However, if you need extra functionality, such as automatic SSL certificate issuance using the ACME DNS challenge via Cloudflare and Let’s Encrypt (as I did), you’ll need an image that includes the required plug-in. You have two options: use a community-maintained prebuilt image (the easy way), or build your own (the hard way). Here, we’re going with the hard way.

Here’s the setup.

1. You have one or more services running in Docker containers.
2. The devices that need to access those services are part of a Tailscale network (Tailnet).
3. You own a public domain name (e.g., your-domain.com)
4. You want/need to serve those services via HTTPS
5. You don’t want to open any ports or other holes in your firewall.
6. You don’t want to mess with self-signed certificates or create your own private certificate authority.

If this is your situation, this post might help.