Reverse proxy generator

Choose the services you want on real hostnames, give it a base domain, and this emits a complete Caddyfile, a set of Traefik v3 labels, nginx server blocks, or a table you can type into Nginx Proxy Manager. It also lists the DNS records to create and points out that one wildcard replaces all of them.

The value is not the boilerplate, which you could write. It is the two per service settings that are only obvious after they have already cost you an evening: which services need a websocket upgrade, and which ones need the body-size limit raised because they move large files. Get the first wrong and a page loads perfectly and then never updates again. Get the second wrong and an upload fails with a 413 that looks exactly like an application bug.

The port for each service comes from the same dataset as its profile, so the generated config points at the port the project actually ships. Everything is assembled in your browser; no domain name, hostname or service list is sent anywhere.

How it works#

Each selected service becomes <slug>.<your domain>, routed to the host you specify on the first port in its profile. Two lookups then modify the output. A websocket list marks services that hold a live connection, which sets proxy_http_version 1.1, the upgrade headers and a one hour read timeout in nginx, and a note in the other outputs. A body-size list marks the services that move large files, which raises the limit to 50 GB for Immich, 10 GB for Nextcloud and Seafile, and 1 GB for Paperless-ngx and Kavita.

The certificate choice changes the output too. HTTP challenge is the default and needs port 80 reachable from the internet. DNS challenge adds the comments for a provider module, and it is the only route to a wildcard or to a certificate for a name that never resolves publicly.

The Caddy output is the shortest because Caddy handles certificates and websockets without being asked. The nginx output is the longest, and it deliberately does not pretend to manage certificates: it points at certbot paths you have to create separately.

What it deliberately does not model#

• Your subdomain scheme. It uses the tool slug. If you want photos rather than immich, edit it, and remember the DNS record has to match.
• Services with several ports. It takes the first. Frigate publishes four and only one of them is the web UI, so check before you paste.
• Subpath hosting. Everything here is one hostname per service. Serving an app under /jellyfin breaks a large fraction of self-hosted software in ways the proxy cannot fix.
• Authentication. No forward auth, no basic auth, no IP allowlists. That is a deliberate omission because it is a decision, not a default.
• The proxy container itself. No compose file for Caddy or Traefik, no ACME email beyond the placeholder, no DNS provider credentials.

What to do with the answer#

Create the DNS records first, ideally the single wildcard, and confirm they resolve before the proxy tries to get a certificate: a failed challenge that is really a DNS propagation delay wastes an hour and can hit rate limits. Then paste the config, reload, and check the websocket services by leaving a live view open for a minute.

After that, decide the access question properly. Reverse proxy and TLS covers certificates and the split between internal and public names, Remote access without port forwarding covers reaching this from outside without opening a port at all, and Single sign-on for self-hosters covers putting one login in front of the lot.