Feedback wanted: reverse proxy (nginx → Caddy?) and aligning the example customization with the mfa-operator

[gpappsoft]

Hi everyone 👋

Firstly, according to the Docker Hub pull stats, quite many people seem to be running this image, but we get very little feedback here on GitHub. So before changing anything in the example stack, I'd like to open this up for discussion. If you're one of the silent users, this is the perfect moment to chime in—even a quick 👍/👎 helps a lot.

Just so expectations are clear: this is still a private project I maintain in my leisure time and has never been an official NetKnights project (the mfa-operator is the exception—that one is developed in a more structured context). So feedback directly shapes where I spend my limited spare time on this repo.

A reminder up front: the image itself stays decoupled from any reverse proxy or database (that's by design). The points below only concern the example/compose stack and the templates/ configuration, not the standalone image.

1. Should we replace nginx with Caddy in the example stack?
   Right now the compose stack uses nginx as the TLS-terminating reverse proxy in front of gunicorn. I'm considering offering Caddy as an alternative (or default).

Pros of Caddy

Much simpler config — a privacyIDEA reverse proxy is essentially a handful of lines in a Caddyfile vs. a full nginx server {} block.
HTTP/2 and HTTP/3 (QUIC) enabled out of the box.
Optional automatic HTTPS via ACME (Let's Encrypt) — handy for real deployments that aren't behind an external LB.
Single static Go binary, sane secure defaults, easy to reason about.
Cons / open questions

The project currently follows a bring-your-own-cert approach (templates/pi.pem / pi.key). Caddy's automatic certificate management partly overlaps with that and could confuse users who already terminate TLS upstream — we'd want to keep the manual-cert path documented.
nginx is the more “boring”/battle-tested choice and what most people already have configs and muscle memory for.
Some users standardize on nginx org-wide and would just rip Caddy back out.
More privacyIDEA community examples exist for nginx today.
A possible compromise: keep nginx as default and ship a Caddy example side-by-side (e.g., a PROFILE or alternative template) so people can pick.

👉 What are you using in front of the container today — nginx, Caddy, Traefik, an external LB, or nothing?

2. Should the example customization be aligned with the mfa-operator?
   There's now a full-featured Kubernetes operator (sec73/mfa-operator) for running privacyIDEA on K8s. It would be nice if the conventions here (config layout, pi.cfg handling, env-var naming, secret handling, entrypoint behavior) didn't drift apart from what the operator expects — so that what you learn from the compose stack carries over to the operator and vice versa.

Concretely this could mean:

Aligning environment-variable names and pi.cfg generation so the same mental model applies in both projects.
Moving from env-var secrets toward file-/secret-based handling (already flagged in the README's security notes) to match how the operator injects secrets in K8s.
Keeping the entrypoint/bootstrap logic compatible so the same image works cleanly under both compose and the operator.
👉 Is anyone using both the compose stack and the operator? Would tighter alignment help you, or do you prefer them evolving independently?

Any feedback – even „we just use it as-is and never touch the proxy“– is genuinely useful for prioritizing. Thanks! 🙏