Use of order directive

[albertopasqualetto]

Hello,
I am really not a pro of Caddy, but is there a way to use the global order directive or something else to use crowdsec in every endpoint?

[hslatman]

Hey @albertopasqualetto,

At the moment there's no such thing, no. One way to make it easier to reuse parts of configuration is to use snippets, but those also need to be imported in each site block. For crowdsec specifically, this doesn't change much, as it's just a single keyword already.

There's this closed issue that seems to propose something for the general case (all configuration directives): caddyserver/caddy#4456. I can see the case for not doing it for all configuration directives, as there could be conflicts in the resulting config and such. It might be possible to do something for just crowdsec, but it would likely require plugging deeper into the configuration parsing logic, and could still be brittle.

I'll keep the issue open for a bit, and might give it a try sometime.

[albertopasqualetto]

Thanks @hslatman

[alex3305]

I wanted to chime on this, because it seems that using order seems to work fine? At least when I implement it along the way of Caddy Security which also uses order directives.

I use caddy-docker-proxy to configure CrowdSec from Compose:

services:
  caddy:
    container_name: caddy
    image: my-own-caddy-container
    restart: on-failure:5
    networks:
      internal:
      ingress:
      ipvlan:
        ipv4_address: 192.168.1.10
        ipv6_address: 1111:1111:1111:1:b00b::135
    volumes:
      - /opt/appdata/caddy/data:/data
      - /opt/appdata/caddy/config:/config
      - /dev/shm/logs/caddy:/var/log/caddy:rw
    command: ["docker-proxy"]
    cap_add:
      - NET_ADMIN

  crowdsec:
    container_name: caddy-crowdsec
    image: ghcr.io/crowdsecurity/crowdsec:v1.6.11
    restart: on-failure:5
    environment:
      COLLECTIONS: "crowdsecurity/caddy"
      GID: "1001"
    networks:
      internal:
    volumes:
      - /opt/appdata/caddy/crowdsec/db:/var/lib/crowdsec/data/
      - /opt/appdata/caddy/crowdsec/config:/etc/crowdsec/
      - /dev/shm/logs/caddy:/var/log/caddy:ro
    labels:
      caddy.crowdsec.api_url: "http://crowdsec:8080"
      caddy.crowdsec.api_key: "[My Super Secret API Key]"
      caddy.crowdsec.ticker_interval: "60s"

networks:
  internal:
    name: caddy-internal
    attachable: true
    driver: overlay
    ipam:
      config:
        - subnet: 10.31.44.0/24

  ingress:
    name: swarm-overlay
    external: true

  ipvlan:
    name: br0
    external: true

Which generates the following Caddyfile

{
  crowdsec {
    api_key [My Super Secret API Key]
    api_url http://crowdsec:8080
    ticker_interval 60s
  }
}

Above this I manually added order crowdsec before reverse_proxy. I could also have done this with another Docker label, but having duplicate label keys can be a bit finicky at times.

I'm not super familiar with Crowdsec, but within a couple of minutes I saw some alerts show up in logging and running docker exec -it caddy-crowdsec cscli alerts list confirmed these alerts:

╭────┬───────────────────┬───────────────────────────────────────┬─────────┬──────────────────────────────────┬───────────┬─────────────────────────────────────────╮
│ ID │       value       │                 reason                │ country │                as                │ decisions │                created_at               │
├────┼───────────────────┼───────────────────────────────────────┼─────────┼──────────────────────────────────┼───────────┼─────────────────────────────────────────┤
│ 4  │ Ip:13.74.29.36    │ crowdsecurity/http-crawl-non_statics  │ IE      │ 8075 MICROSOFT-CORP-MSN-AS-BLOCK │ ban:1     │ 2025-08-12 12:25:52.745948521 +0000 UTC │
│ 3  │ Ip:13.74.29.36    │ crowdsecurity/http-backdoors-attempts │ IE      │ 8075 MICROSOFT-CORP-MSN-AS-BLOCK │ ban:1     │ 2025-08-12 12:26:14.611698387 +0000 UTC │
│ 2  │ Ip:172.207.240.95 │ crowdsecurity/http-crawl-non_statics  │ JP      │ 8075 MICROSOFT-CORP-MSN-AS-BLOCK │ ban:1     │ 2025-08-12 12:21:27.299488536 +0000 UTC │
╰────┴───────────────────┴───────────────────────────────────────┴─────────┴──────────────────────────────────┴───────────┴─────────────────────────────────────────╯

Normally I would just add the crowdsec directive to my domain handler(s), but it just doesn't seem to fit with my current setup with wildcard certificates. Those are formatted something like this

(common) {
  encode zstd gzip
  tls {
    dns cloudflare SomeApiKeyHere
  }
  handle {
    redir {args[0]}
  }
}

*.example.com {
  @some-app {
    host app.example.com
  }

  handle @some-app {
    reverse_proxy 10.0.0.2:3000
  }

  import common https://google.com
  log access
}

Adding crowdsec to the wildcard block (my preference) yields an error. And adding Crowdsec to every upstream seems a bit convoluted for me. Since I probably want to secure every endpoint anyway.

Maybe you @hslatman can shed some light on this?

[hslatman]

Hey @alex3305, yes, order should work fine, as it's part of the global Caddy configuration, and thus nothing specific to CrowdSec. It only affects the ordering of directives that are configured, though; it doesn't add them globally. At least afaik.

What @albertopasqualetto is looking for is a way to globally enable the CrowdSec bouncer for all servers/routes, similar to the global order directive. Afaik, that is currently not possible, as it would require changing the configuration for each server/route block. Your common snippet could in fact be used to set crowdsec for each, but that's slightly different from what @albertopasqualetto would like to have.

That said, it's interesting to see that it looks like CrowdSec is acting on something. Are you sure it's acting on requests from Caddy, or is it possibly a different bouncer that's also interacting with your LAPI? Does the complete configuration that Caddy Docker Proxy generates include crowdsec for the servers too?

[alex3305]

Thanks for your insight @hslatman 😄 .

@hslatman
It only affects the ordering of directives that are configured, though; it doesn't add them globally. At least afaik.

I think it does, but that's how I interpret the directive order documentation:

Caddy Documentation:
Many directives manipulate the HTTP handler chain. The order in which those directives are evaluated matters, so a default ordering is hard-coded into Caddy.

You can override/customize this ordering by using the order global option or the route directive.

I read that as if I modify the order, it will in fact modify the (global) http handler chain. So if I add the crowdsec directive into the http handler chain, it will be used for the applicable chain. Which is the global chain when I place it global configuration block. The order documentation also mentions this usage (emphasis mine):

Caddy Documentation:
Assigns an order to HTTP handler directive(s). As HTTP handlers execute in a sequential chain, it is necessary for the handlers to be executed in the right order. Standard directives have a pre-defined order, but if using third-party HTTP handler modules, you'll need to define the order explicitly by either using this option or placing the directive in a route block. Ordering can be described absolutely (first or last), or relatively (before or after) to another directive.

Again, I can be wrong 🤷. But that's how I interpret the docs 😉 .

I'm familiar with this usage from using Caddy Security, which uses the order for authentication and authorization:

{
	order authenticate before respond
	order authorize before basicauth
}

@hslatman
[...] Your common snippet could in fact be used to set crowdsec for each, but that's slightly different from what @albertopasqualetto would like to have.

Sure. But I have the same goal, either with or without a common snippet. I'm just wondering if a common snippet would even work because if I place the crowdsec directive within a (sub)domain block, like this:

*.example.com {
  @some-app {
    host app.example.com
  }

  handle @some-app {
    reverse_proxy 10.0.0.2:3000
  }

  import common https://google.com
  log access
  crowdsec  # <--- this is invalid here
}

Caddy complains that the crowdsec directive is not in a route block. Which it of course isn't 😛.

@hslatman
That said, it's interesting to see that it looks like CrowdSec is acting on something. Are you sure it's acting on requests from Caddy, or is it possibly a different bouncer that's also interacting with your LAPI?

No. 100% only Caddy.

$ docker exec -it caddy-crowdsec cscli bouncers list
───────────────────────────────────────────────────────────────────────────────────────────────
 Name           IP Address   Valid  Last API pull         Type              Version  Auth Type
───────────────────────────────────────────────────────────────────────────────────────────────
 caddy-bouncer  10.31.44.33  ✔️     2025-08-12T13:48:27Z  caddy-cs-bouncer  v0.9.2   api-key
───────────────────────────────────────────────────────────────────────────────────────────────

CrowdSec is also only exposed to the internal Caddy network as per my Compose above. This is an internal network that has only a couple of containers connected:

• Caddy in Docker Proxy Server mode
• Caddy in Docker Proxy Controller mode
• 2× Docker Socket Proxy (1 per host)
• CrowdSec

@hslatman
Does the complete configuration that Caddy Docker Proxy generates include crowdsec for the servers too?

No. Only from my base Caddyfile:

$ wc -l /config/caddy/Caddyfile.autosave
578

$ grep -wc 'crowdsec' /config/caddy/Caddyfile.autosave
3

$ grep -i 'crowdsec' /config/caddy/Caddyfile.autosave
        order crowdsec before reverse_proxy
        crowdsec {
                api_url http://crowdsec:8080

I also tried removing the crowdsec directive from my Caddyfile for an hour and reports also stopped. In the mean time requests to /v1/decisions/stream kept coming in every minute from the Caddy container.

[hslatman]

Thanks for your insight @hslatman 😄 .

@hslatman
It only affects the ordering of directives that are configured, though; it doesn't add them globally. At least afaik.

I think it does, but that's how I interpret the directive order documentation:

Caddy Documentation:
Many directives manipulate the HTTP handler chain. The order in which those directives are evaluated matters, so a default ordering is hard-coded into Caddy.
You can override/customize this ordering by using the order global option or the route directive.

I read that as if I modify the order, it will in fact modify the (global) http handler chain. So if I add the crowdsec directive into the http handler chain, it will be used for the applicable chain. Which is the global chain when I place it global configuration block. The order documentation also mentions this usage (emphasis mine):

Caddy Documentation:
Assigns an order to HTTP handler directive(s). As HTTP handlers execute in a sequential chain, it is necessary for the handlers to be executed in the right order. Standard directives have a pre-defined order, but if using third-party HTTP handler modules, you'll need to define the order explicitly by either using this option or placing the directive in a route block. Ordering can be described absolutely (first or last), or relatively (before or after) to another directive.

Again, I can be wrong 🤷. But that's how I interpret the docs 😉 .

The crowdsec part that goes in the global part of the config affects the configuration of the (shared) core of the module. That core is responsible for polling the LAPI. It doesn't create handlers/matchers for each route, automatically. So, if those are not part of the server/route blocks, then I believe order shouldn't affect them. But if it does, then it's a TIL. Will need to verify this manually.

I'm familiar with this usage from using Caddy Security, which uses the order for authentication and authorization:

{
order authenticate before respond
order authorize before basicauth
}

True, but in the complete Caddyfile it would still need authenticate and authorize to be specified for them to be active, afaik, e.g.: https://github.com/authcrunch/authcrunch.github.io/blob/main/assets/conf/ldap/Caddyfile#L89-L103. The non-global crowdsec directive works the same way.

@hslatman
[...] Your common snippet could in fact be used to set crowdsec for each, but that's slightly different from what @albertopasqualetto would like to have.

Sure. But I have the same goal, either with or without a common snippet. I'm just wondering if a common snippet would even work because if I place the crowdsec directive within a (sub)domain block, like this:

*.example.com {
@some-app {
host app.example.com
}

handle @some-app {
reverse_proxy 10.0.0.2:3000
}

import common https://google.com
log access
crowdsec # <--- this is invalid here
}

Caddy complains that the crowdsec directive is not in a route block. Which it of course isn't 😛.

@hslatman
That said, it's interesting to see that it looks like CrowdSec is acting on something. Are you sure it's acting on requests from Caddy, or is it possibly a different bouncer that's also interacting with your LAPI?

No. 100% only Caddy.

$ docker exec -it caddy-crowdsec cscli bouncers list
───────────────────────────────────────────────────────────────────────────────────────────────
 Name           IP Address   Valid  Last API pull         Type              Version  Auth Type
───────────────────────────────────────────────────────────────────────────────────────────────
 caddy-bouncer  10.31.44.33  ✔️     2025-08-12T13:48:27Z  caddy-cs-bouncer  v0.9.2   api-key
───────────────────────────────────────────────────────────────────────────────────────────────

CrowdSec is also only exposed to the internal Caddy network as per my Compose above. This is an internal network that has only a couple of containers connected:

* Caddy in [Docker Proxy Server](https://github.com/lucaslorentz/caddy-docker-proxy?tab=readme-ov-file#server) mode

* Caddy in [Docker Proxy Controller](https://github.com/lucaslorentz/caddy-docker-proxy?tab=readme-ov-file#controller) mode

* 2× Docker Socket Proxy (1 per host)

* CrowdSec

@hslatman
Does the complete configuration that Caddy Docker Proxy generates include crowdsec for the servers too?

No. Only from my base Caddyfile:

$ wc -l /config/caddy/Caddyfile.autosave
578

$ grep -wc 'crowdsec' /config/caddy/Caddyfile.autosave
3

$ grep -i 'crowdsec' /config/caddy/Caddyfile.autosave
        order crowdsec before reverse_proxy
        crowdsec {
                api_url http://crowdsec:8080

I also tried removing the crowdsec directive from my Caddyfile for an hour and reports also stopped. In the mean time requests to /v1/decisions/stream kept coming in every minute from the Caddy container.

Not sure what's going on there, then. I have seen quite a few interesting things and bugs happening when this bouncer is used with Caddy Docker Proxy, so I suspected something weird was going on again.

[alex3305]

True, but in the complete Caddyfile it would still need authenticate and authorize to be specified for them to be active, afaik, e.g.: https://github.com/authcrunch/authcrunch.github.io/blob/main/assets/conf/ldap/Caddyfile#L89-L103. The non-global crowdsec directive works the same way.

I assume this is because Caddy Security has no default authorization policy defined. So it passes through the plugin, but allows is. But that's my assumption.

Not sure what's going on there, then. I have seen quite a few interesting things and bugs happening when this bouncer is used with Caddy Docker Proxy, so I suspected something weird was going on again.

I know 😆. But most of that is related to PEBCAK 🤷 .

Edit: Follow up. It seems that CrowdSec banning is indeed not working with only order. But it detects and marks traffic just fine. Thanks again for your insights 😄 .

Edit: Another follow up. I did had to have the global order set in order to use it as a directive. So

{
  order crowdsec before reverse_proxy # <-- This is needed for...
}

*.example.com {
  @some-app {
    host app.example.com
  }

  handle @some-app {
    crowdsec     # <--- ...this to work
    reverse_proxy 10.0.0.2:3000
  }
}

[FutureCow]

For me this is working for all my subdomains:

{
        crowdsec {
                api_url http://127.0.0.1:8080
                api_key 
        }
        order crowdsec before reverse_proxy
}

*.domain.com {
        tls {
                dns apikey
        }
        log {
                level INFO
                output file /var/log/caddy/access.domain.com.log
        }
        crowdsec
        @app1 host app1.domain.com
        handle @app1 {
                reverse_proxy 192.168.1.101:80
                }
        }
        @app2 host app2.domain.com
        handle @app2 {
                reverse_proxy 192.168.1.102:80
                }
        }
etc...
}

[nicolazilio]

Hi @hslatman,

just FYI, I also had to resort to using the order directive

order crowdsec first
order appsec after crowdsec

because converting the following to a route by simply replacing handle with route (without understanding the implications, admittedly not the smartest approach)

handle @grafana-public-external {
        crowdsec
        appsec
        authorize with auth_policy
        reverse_proxy grafana:3000 {
                header_down X-Frame-Options "SAMEORIGIN"
        }
        log_name crowdsec-monitor
}

apparently 'disabled' the X-Frame-Options header, for some reason (didn't have time to investigate the issue more).

(BTW, adding those order directives only affects the ordering of the directives that are configured in a block)

[nebb00]

Not sure why, but if I ban my IP, i get the crowdsec ban page for private-app but not for public, even tho i get a 403. I do use order crowdsec first in my global config

(private-app) {
        handle /caddy-security/* {
                authenticate with myportal
        }

        @private {
                import private-ips
        }

        handle @private {
                crowdsec
                authorize with mypolicy
                reverse_proxy {args[0]}
        }

        handle {
                respond "Access denied" 403
        }
}

(public-app) {
       handle /* {
                crowdsec
                reverse_proxy {args[0]}
       }
}