Allow custom Caddy configuration inside the generated Coolify management vhost

[sebastien3k]

Related to #10332 and the routing limitations discussed in #10303.

I have a similar management-plane access-control requirement, but a simple dashboard IP allowlist is not sufficient in my case.

I want the Coolify dashboard, realtime endpoint, and terminal endpoint accessible only over Tailscale/private networking, while keeping a very small part of the Coolify API, specifically /api/v1/deploy, publicly reachable for deployment webhooks.

With Caddy, Coolify currently generates and owns coolify.caddy, roughly:

https://coolify.example.com {
    handle /app/* {
        reverse_proxy coolify-realtime:6001
    }

    handle /terminal/ws {
        reverse_proxy coolify-realtime:6002
    }

    reverse_proxy coolify:8080
}

Because the final proxy covers the whole hostname, restricting access externally is difficult without either duplicating Coolify's internal routing or modifying a file that Coolify regenerates.

Would you be open to adding a supported advanced-user Caddy extension point inside this generated site block, while keeping coolify.caddy itself managed/read-only?

Conceptually:

https://coolify.example.com {
    import /dynamic/coolify-custom/*.caddy

    handle /app/* {
        reverse_proxy coolify-realtime:6001
    }

    handle /terminal/ws {
        reverse_proxy coolify-realtime:6002
    }

    reverse_proxy coolify:8080
}

Coolify would continue owning the domain, TLS, internal service names, realtime/terminal routing, and regeneration. Advanced users would only own the imported fragment.

This would support cases such as:

private/Tailscale-only dashboard access
keeping /api/v1/deploy publicly reachable
office/VPN IP restrictions
other Caddy-native access-control policies

without requiring users to replace or duplicate Coolify's generated management configuration.

Since Coolify already supports additional Caddy dynamic configuration files, this seems like a relatively small extension of the existing model.

I’m willing to implement and test this as a PR immediately if this approach fits the project direction. I’d keep the initial change intentionally narrow and backward-compatible: no custom fragment means unchanged behavior, validate before reload, and provide an obvious reset/recovery path.

[Cinzya]

As far as I know, Coolify only generates / edit the coolify.caddy when you configure the instance URL under Settings > General > URL. If you leave that empty, you can then pass your own Caddyfile with the needed configs you want for the Coolify Dashboard.

You aren't the only one who wants to make custom edits to this. Maybe it can be solved in the similar way as with the ready only mode of the Container Labels in Applications. Where enabling a checkbox in the General Settings, would disable coolify altering the coolify.caddy so users can alter it to their own liking.

[sebastien3k]

Thanks, I dug into that workaround a little further and I think the Container Labels-style ownership toggle may be the cleaner solution.

One issue with leaving Settings > General > URL empty is that the instance FQDN is also used as Coolify's canonical base URL. generateDeployWebhook() and the manual Git provider webhook generators both derive their URLs from base_url(), which prefers the configured instance FQDN and otherwise falls back to the server address.

So clearing the instance URL lets the user take over coolify.caddy, but also changes Coolify's generated deploy/manual webhook URLs and potentially other places that need the canonical instance URL.

That makes me think these concerns should probably be separate:

• Instance URL remains configured and continues to define Coolify's canonical URL.
• A separate "Managed by Coolify / Managed manually" setting controls ownership of coolify.caddy.

That seems very similar to the existing Container Labels management pattern and avoids requiring users to give up normal URL/webhook generation just to customize the management vhost.

[Cinzya]

I could be wrong here, but I believe the Webhook URLs should still work regardless of that fact. Coolify just generates them based on your server public ip address for you to copy in the UI in this case, but that doesn't mean, that you can't hit them over your URL as well. So just manually replacing the public ip with your URL should still work.

[sebastien3k]

Yeah, agreed, from GitHub’s side this can be made to work too: the webhook URL can be edited directly there, and as long as a custom coolify.caddy routes that domain back to Coolify, the requests should land.

My concern is that this makes a pretty important deployment path depend on a manual workaround spread across a few places, instead of something Coolify clearly understands and manages.

The Container Labels-style approach could make manual ownership of coolify.caddy a first-class state. Would a small PR make sense that keeps the dashboard URL as the source of truth, then adds a separate default-enabled setting for whether Coolify writes coolify.caddy?