How to limit access to Coolify Dashboard by IP address?

[Talkless]

At the beginning, I had the impression that Dashboard is only accessible via 8000 port.

But once SSL works, Dashboard is also accessible via domain, like https://coolify.example.com.

If Dashboard would be accessible ONLY via 8000, I could configure iptables (latest Docker has nftables experimental support with much cleaner setup) to allow 8000 port ONLY for specific IP addresses. But it's not TLS...

So now our Dashoard is accessible for anyone, and we don't have failed login logs of sorts to ban password attempts, for example...

So, is there simple way to have Dashboard accessible via HTTPS (not HTTP 8000), but only from limited IP addresses (actually one is enough - our office)?

Thanks.

[panic-Patrick]

The problem is that once SSL is set up, the dashboard is reachable via the domain on 443 and not just port 8000 anymore. And there's no built-in way in Coolify to restrict that to certain IPs.
Haven't tested this myself yet, but it should work based on how Traefik handles dynamic configs. The idea is to drop a config file into /data/coolify/proxy/dynamic/ and Traefik picks it up without a restart:

http:
  middlewares:
    dashboard-ip-allowlist:
      ipAllowList:
        sourceRange:
          - "203.0.113.42/32"  # office IP
          - "127.0.0.1/32"

  routers:
    coolify-dashboard:
      middlewares:
        - dashboard-ip-allowlist

Also make sure /data/coolify/proxy/traefik.yaml has the file provider configured:

providers:
  file:
    directory: /data/coolify/proxy/dynamic
    watch: true

Anyone not on the list gets a 403. If your office IP is dynamic you'll need to update that automatically somehow, or go the VPN route instead.
Would be curious if anyone has tried this and happy to hear if it needs any tweaks for Coolify's setup.

[Talkless]

Thans @panic-Patrick for suggestion.

I've creaded file /data/coolify/proxy/dynamic/restrict-dashboard.yaml in my testing VirtualBox machine:

http:
  middlewares:
    dashboard-ip-allowlist:
      ipAllowList:
        sourceRange:
          - 0.0.0.0/32
  routers:
    coolify-https:
      middlewares:
        - dashboard-ip-allowlist
    coolify-http:
      middlewares:
        - dashboard-ip-allowlist

(coolify.yaml has coolify-https and coolify-http routers, not coolify-dashboard)

After reloading proxy, I see this file in Dynamic Configuration page (so I assume it's loaded), but blocking (0.0.0.0 should not allow anything?) does not work:

[panic-Patrick]

Looked into this a bit more and I think the reason 0.0.0.0/32 doesn't block anything is that Traefik isn't actually attaching the middleware. Coolify generates coolify.yaml automatically and defines coolify-http and coolify-https there. When you define a router with the same name in a second file, Traefik treats it as a duplicate and logs Router defined multiple times with different configurations, which causes the conflicting router to be discarded instead of merged. So the middleware never ends up on the live router.
Editing coolify.yaml directly isn't a clean fix either, since Coolify regenerates it.
What should work is defining a new router with a different name and a higher priority that catches the same host. The standard coolify-https router has lower priority, so the new one wins:

http:
  middlewares:
    dashboard-ip-allowlist:
      ipAllowList:
        sourceRange:
          - 1.2.3.4/32   # office IP
  routers:
    coolify-https-restricted:
      rule: "Host(`coolify.example.com`)"
      entryPoints:
        - https
      service: coolify
      tls:
        certResolver: letsencrypt
      priority: 2000
      middlewares:
        - dashboard-ip-allowlist
    coolify-http-restricted:
      rule: "Host(`coolify.example.com`)"
      entryPoints:
        - http
      service: coolify
      priority: 2000
      middlewares:
        - dashboard-ip-allowlist

Replace coolify.example.com with the actual dashboard domain. Worth checking the Traefik logs after reload to confirm there are no duplicate-router warnings and that the new router is the one matching requests. If Coolify sits behind Cloudflare or another upstream proxy, ipStrategy.depth: 1 is also needed so Traefik reads the real client IP from X-Forwarded-For instead of the proxy's IP.

[Cinzya]

You could empty the Domain field under the Coolify settings. The router rule in the coolify.yaml should also disappear and you can create your own routers in a new dynamic config.

[Talkless]

So in principle, Coolify could always use that middleware with 0.0.0.0/0 and ::/0 range by default, and implement allow list configuration in Dashboard?

I mean, since Coolify generates .yaml file, it could add in that middleware dynamically too, right?

[yudin-s]

Your 0.0.0.0/32 test is a good one: if that middleware were attached to the active dashboard router, normal clients should be blocked. Since it is not blocking, I would assume the middleware is loaded but not actually being used by the router that serves the dashboard.

I would debug it from Traefik's dynamic config view/API rather than from the YAML file alone:

1. Find the actual router handling coolify.example.com.
2. Check whether that router shows dashboard-ip-allowlist in its middleware list.
3. Check whether the router is coming from the same provider/file you are editing.

The important distinction is: loading a middleware is not enough; the active router must reference it.

For the test config, I would also avoid 0.0.0.0/32 and use your real office IP first:

http:
  middlewares:
    dashboard-ip-allowlist:
      ipAllowList:
        sourceRange:
          - "203.0.113.42/32"

Then attach it to the exact active routers shown by Traefik, for example only if those are really the generated router names:

http:
  routers:
    coolify-https:
      middlewares:
        - dashboard-ip-allowlist
    coolify-http:
      middlewares:
        - dashboard-ip-allowlist

If there is another proxy/CDN in front of Coolify, the client IP seen by Traefik may be the proxy IP, not your office IP. In that case you need to configure forwarded headers / IP strategy correctly, otherwise the allowlist will be checking the wrong address.

For production, I would still prefer VPN or an upstream firewall rule if possible. A Traefik middleware can work, but Coolify may regenerate its proxy config, so any manual router-level change should be treated as something to re-check after upgrades/restarts.

If this solves it, please mark this comment as the answer so other people can find it faster.

[Talkless]

I've tried your example with custom router using priority: 2000, but I get strange 419 error on login (login form loads, but clicking login button results in 419)

[panic-Patrick]

The 419 is a Laravel "Page Expired" / CSRF mismatch, and it's almost certainly because the new router with Host() and priority: 2000 is also catching the WebSocket traffic that Coolify normally routes through its realtime-ws and terminal-ws routers. Livewire (which Coolify uses) needs those WebSocket connections to keep CSRF/session state consistent, and when they get routed through the generic coolify service instead, login submissions break.
Two ways to fix it:
Option A — exclude the WebSocket paths from the new router (similar to what the Coolify Tweaks project does):

coolify-https-restricted:
  rule: "Host(`coolify.example.com`) && !PathPrefix(`/app`) && !PathPrefix(`/terminal/ws`)"
  entryPoints:
    - https
  service: coolify
  tls:
    certResolver: letsencrypt
  priority: 2000
  middlewares:
    - dashboard-ip-allowlist

Downside: the WebSocket endpoints stay unprotected by the IP allowlist. In practice not a huge deal because those endpoints require an authenticated session anyway, but worth being aware of.
Option B — add restricted versions for the WebSocket routers too:

realtime-ws-restricted:
  rule: "Host(`coolify.example.com`) && PathPrefix(`/app`)"
  entryPoints:
    - https
  service: realtime-ws
  tls:
    certResolver: letsencrypt
  priority: 2500
  middlewares:
    - dashboard-ip-allowlist
terminal-ws-restricted:
  rule: "Host(`coolify.example.com`) && PathPrefix(`/terminal/ws`)"
  entryPoints:
    - https
  service: terminal-ws
  tls:
    certResolver: letsencrypt
  priority: 2500
  middlewares:
    - dashboard-ip-allowlist

Higher priority than the main restricted router so the path matching wins.
Honestly, after digging into this I think @yudin-s has a fair point about nftables/upstream firewall being more robust for production. The Traefik approach works but it's fragile, since Coolify regenerates coolify.yaml and adds new internal routes (like terminal-ws) over time. Any new internal router added by future Coolify versions would need to be mirrored here as well.
For your original idea about Coolify shipping this as a built-in feature: yes, that would be the cleanest solution, since Coolify owns the config generation and could keep the middleware attached to all internal routers automatically. Worth opening a feature request.

[Talkless]

It's just too complicated, I should just create Feature Request issue.

Firewall would work if we have Dashboard accessible only via some specific port, but it also should be TLS.

[Talkless]

Creaded #10332

[Talkless]

Thanks @yudin-s @panic-Patrick for your detailed input!

[yudin-s]

Thanks. I think opening the feature request is the right path here.

One useful acceptance criterion for a built-in Coolify version would be: the allowlist has to be attached by Coolify's own config generator to every dashboard-related router, including the realtime/terminal WebSocket routers. Otherwise a manual Traefik overlay can easily protect the main page while accidentally breaking login/session behavior or missing a newly generated internal route after an upgrade.

It would also be worth making IPv4/IPv6 and "behind another proxy/CDN" behavior explicit in the UI/docs, because the allowlist is only as good as the client IP Traefik actually sees.

[Talkless]

I think opening the feature request is the right path here.

Please upvote that feature request if you believe it's worth it.