I’m not sure I see what the need for FlareSolverr is, as I understand it it’s a reverse proxy that will add the cloudflare authentication cookies so that your *arr apps can access prowlarr, however you should just be able to stick them on a named bridge network and access them internally by container name.

I think using FlareSolverr is adding unnecessary complexity as you shouldn’t need to make an internet round trip for containers to access each other.

I have all my internet facing stuff behind Authelia with 2fa but it still works because the containers talk to each other on their own network directly.

I wrote something that can setup caddy automatically from docker labels.

It’s not well documented as I mostly wrote it for myself. https://hub.docker.com/r/mheys1/docker-dynamic-caddy https://github.com/mattheys/ddc

It basically acts like a DNS server serving up SRV records that caddy can use for dynamic configuration, I added in an on_demand_tls endpoint as well so that you don’t get spammed for non existent TLS records.

I see no one has mentioned Kong, it’s an api gateway that can reverse proxy your api requests but it’s so much more than that. It can do all sorts of pipelining to do stuff like add JWT, OAuth or Key authentication, rate limiting plus more. You can run it in a docker container too.

If you are writing your own playwright tests do you have the skills to wrap these up in a web api? If so you can then use uptime-kuma to call your playwright tests and return 200 if it’s ok or something else if not, Kuma will show the status code history in the dashboard so you could use specific codes for specific reasons, just try and keep them close to official. Or you could setup NodeRed to log more detailed responses to a database but you would then need to do more work to make a pretty way of displaying that, Grafana maybe?