Current problem
deploy/self-hosting/docker-compose.yml assumes it owns the host's web ports and that the operator generates every secret by hand before the first start. Both assumptions break when the stack is deployed by a PaaS layer (Coolify, Dokploy, CapRover) or placed behind an existing reverse proxy, so the file has to be forked and patched, then re-patched on every upstream change.
Two specifics.
1. caddy publishes the host's web ports unconditionally.
caddy :
ports :
- "80:80"
- "443:443"
- "443:443/udp" FLUXER_CADDY_SITE_ADDRESS=:80 is documented for the Cloudflare Tunnel case, and FLUXER_PUBLIC_SCHEME / FLUXER_PUBLIC_PORT already describe the browser-facing side independently. Only the hardcoded port mapping stands in the way.
2. VAPID keys can't be produced by an automated deployment layer.
FLUXER_VAPID_PUBLIC_KEY and FLUXER_VAPID_PRIVATE_KEY are mandatory (:?), and the documented way to produce them is:
docker run --rm node:24-alpine npx --yes web-push generate-vapid-keys --json
openssl rand. This one is an EC P-256 keypair, so it's the only value a PaaS secret generator can't fill in, since those generate random strings and passwords, not keypairs.Proposed change
1. Make the
Gating the whole block behind a Compose profile would work equally well. Either way an operator behind a proxy can bind to loopback or skip publishing without editing the file, and the defaults stay exactly as they are today.
2. When both VAPID variables are empty, have the API generate a keypair on first boot, persist it (Postgres or the existing object storage) and log the public key. Explicitly set values keep overriding it. This also drops a step from the manual quick start.
Together these make the published Compose file deployable behind any external proxy with environment variables alone.
caddy port mapping configurable rather than hardcoded, e.g.
ports :
- "${FLUXER_HTTP_BIND:-80}:80"
- "${FLUXER_HTTPS_BIND:-443}:443"
- "${FLUXER_HTTPS_BIND:-443}:443/udp"