How I Locked Myself Out While Securing My Website with Caddy Proxy (And Fixed It)

How I Locked Myself Out While Securing My Website with Caddy Proxy (And Fixed It)
Breaking my server with Caddy Proxy

By using Platform-as-a-Service tool coolify, I am deploying so many different cool and useful services like my personal website, this blog or a dashy dashboard.

Since I want to have personal and sensitive material on my dashy, it cannot be public!
The plan? Secure the private services on my server, so they wouldn’t be exposed to the world. Easy, right? Not exactly.

I started with Dashy’s authentication guide, trying everything from HTTPAuth to Keycloak, but nothing worked. Frustrated, I decided to use Caddy’s dynamic authentication file. It’s a simple solution: just drop a configuration file into Caddy’s dynamic folder, and you´re good to go. Or so I thought.

In coolify, the proxy settings are found in Server -> localhost -> Proxy.

Caddy Proxy configuration in Coolify Dashboard

The Mistake: Overwriting all subdomains

I added the below setup as dynamic caddy configuration:

(secure) {
    basicauth /* {
        admin JDJhJDE0JHh5ei4uLg==
    }
}

# Catch all other subdomains and protect them
*.marvinottersberg.de {
    import secure
    # Skip the domains we want public
    @notPublic {
        not host marvinottersberg.de
        not host blog.marvinottersberg.de
    }
    handle @notPublic {
        reverse_proxy {upstream}
    }
}

I used this tool to generate a bcrypt-encrypted password.

Feeling confident, I uploaded the file through Coolify’s dashboard and hit save.

Cue disaster.

The Fallout: Locking myself out of the server

Instead of my beautiful dashboard, I was greeted with this:

This site can’t provide a secure connection
ERR_SSL_PROTOCOL_ERROR

Worse still, I had managed to lock myself out of my Coolify dashboard. Great!

The Fix: Setting Up Caddy Proxy the Right Way

Here’s what I did to fix it.
I logged into my server with SSH and removed my newly created basicauth.caddy file from the /dynamic folder and restart the coolify-proxy container. I followed these steps:

  1. On your instance, find the Docker proxy container name or id:
docker ps | grep -i "coolify.*proxy"
# Output:  5571e373e2d1   lucaslorentz/caddy-docker-proxy:2.8-alpine                          "/bin/caddy docker-p…"   2 weeks ago      Up 3 minutes             0.0.0.0:80->80/tcp, :::80->80/tcp, 0.0.0.0:443->443/tcp, :::443->443/tcp, 0.0.0.0:443->443/udp, :::443->443/udp, 2019/tcp   coolify-proxy
  1. Locate your Caddyfile inside proxy container:
docker exec -it coolify-proxy sh -c "find / -name 'Caddyfile' 2>/dev/null"`
# Output:   /dynamic/Caddyfile
  1. Deleted the problematic file that broke everything:
docker exec -it coolify-proxy sh -c "rm -rf /dynamic/basicauth.caddy"
  1. Restart the proxy:
docker restart coolify-proxy

Securing it properly

Afterwards, I simplified this caddy configuration and only added it for each subdomain individually.

dashboard.marvinottersberg.de {
    basicauth /* {
        <username> <bcrypt_encrypted_password>
    }
    reverse_proxy /* dashy-ikk4gkgggs8w4g4k480kgw4s:8080 {
        header_up Host {host}
    }
}

It is important to connect the service to coolify pre-defined network via the service stack settings.
Also, service discovery in coolify is achieved via the service name, dashy-ikk4gkgggs8w4g4k480kgw4s and not via localhost.
The reverse proxy must point to that name and their port.

Final words

There you have it. If you want to secure your website, don't be like me. Don't break your server proxy 😅

Hope you have a great day
Cheers, Marvin ✌️

Marvin Ottersberg

Marvin Ottersberg

I am a cloud developer with a wanderlust heart. My remote work allows me the freedom to blend my passion for coding with a love for travel. I enjoy developing solutions and make an impact..