Do I need to configure TLS/certificates manually?

No. Caddy's defining feature is automatic HTTPS: as soon as a Caddyfile block has a real domain name as its address, Caddy automatically obtains and renews a Let's Encrypt certificate for it with zero extra directives, which is why this generator has no SSL toggle at all.

What happens when both reverse_proxy and file_server are enabled?

The generator scopes the reverse_proxy directive to the /api/* path so it doesn't conflict with file_server handling everything else. Caddy directives don't layer by file order the way some other servers' location blocks do, so an explicit path matcher like /api/* is how you split traffic between a backend API and static files in the same site block.

Is the header block here setting request or response headers?

Response headers. The `header { ... }` block sets headers on responses Caddy sends back to the client, the same purpose as Nginx's add_header or Apache's Header always set, useful for security headers like X-Frame-Options.

Why is there no listen-port directive like Nginx's `listen 80`?

The Caddyfile's site address itself (e.g. `example.com`) implies the correct port and protocol, Caddy infers :443 with HTTPS for a bare domain and only needs an explicit port for non-standard setups. This keeps the generated block shorter than an equivalent Nginx/Apache config.

Caddyfile Generator - Reverse Proxy + File Server

Overview

Introduction

Caddy's whole pitch is that a working HTTPS site is a few lines shorter than the equivalent Nginx or Apache config, since certificate management just isn't something you write directives for. That doesn't mean there's nothing to get right: mixing a reverse proxy with static file serving on the same domain still needs a path matcher.

This tool generates a Caddyfile block for a domain, with a reverse proxy target, an optional file server, and a response header block, keeping the reverse-proxy-vs-static split correct when both are enabled.

What Is Caddyfile Generator?

A generator for a single Caddyfile site block: the domain as the address (which is what triggers Caddy's automatic HTTPS), an optional reverse_proxy directive, an optional file_server plus root for serving static files, and an optional header block for response headers.

When both reverse_proxy and file_server are enabled, the reverse proxy is scoped to an /api/* path matcher so static files and proxied API routes coexist in the same block without conflicting.

How Caddyfile Generator Works

You enter a domain, a reverse_proxy target (host:port), toggle the file server with a document root, and add response headers as key/value rows. The generator validates the domain format and requires at least a proxy target or the file server.

It emits a Caddyfile block: a comment noting automatic HTTPS applies with no extra directives, the reverse_proxy and/or root+file_server lines, and a header block if any headers were added.

When To Use Caddyfile Generator

Use it when standing up a new Caddy-served site or API gateway and you want the reverse_proxy/file_server split done correctly from the start.

It's also a fast way to get a baseline Caddyfile when migrating a simple Nginx or Apache site to Caddy for its simpler TLS story.

Often used alongside Nginx Reverse Proxy Generator, Apache VirtualHost Generator and Let's Encrypt Config Generator.

Features

Advantages

Never requires you to write certificate directives, matching Caddy's actual automatic-HTTPS behavior instead of pretending you need to configure it.
Automatically applies an /api/* path matcher when combining a reverse proxy with a file server, avoiding a silent directive conflict.
Keeps response headers in Caddy's real `header { ... }` block syntax rather than a generic key-value dump.

Limitations

The /api/* path convention for combined mode is a sensible default, not universal, adjust it manually if your API lives under a different prefix.
Doesn't cover Caddy's more advanced routing (named matchers, handle blocks with multiple backends) — see the load balancer generator for multi-backend setups.

Examples

Reverse proxy with security headers, no file server

Input

domain: api.example.com, reverseProxyTarget: 127.0.0.1:3000, fileServerEnabled: false, headers: [{key: X-Frame-Options, value: SAMEORIGIN}]

Output

api.example.com {
    # Automatic HTTPS is implicit...

    reverse_proxy 127.0.0.1:3000

    header {
        X-Frame-Options SAMEORIGIN
    }
}

With file_server off, reverse_proxy handles every request to the domain directly, no path matcher is needed.

Best Practices & Notes

Best Practices

Let Caddy manage certificates automatically rather than importing an externally issued certificate unless you have a specific reason to (an internal CA, a wildcard cert already on hand).
Scope reverse_proxy to a specific path when it coexists with file_server, so static assets and API routes don't silently shadow each other.
Keep the header block focused on response headers you actually need (security headers, cache-control), Caddy already sets sane defaults for most of the rest.

Developer Notes

Caddy's automatic HTTPS triggers whenever a site block's address looks like a real, publicly resolvable domain (not `localhost` or an IP), it then handles ACME issuance and renewal via its embedded certmagic library with zero Caddyfile directives required. The `reverse_proxy` and `file_server` directives are both part of Caddy's default directive order, when both are present without a path matcher, Caddy would evaluate them in the fixed internal order rather than a source-order 'first match wins' the way some other servers behave, which is why an explicit path matcher (like `/api/*`) is the correct way to split traffic between them in one block.

Caddyfile Generator Use Cases

Standing up a new Caddy site with zero-config HTTPS in front of an app server
Serving a static frontend and proxying an API from the same domain and Caddy instance
Migrating a simple Nginx/Apache virtual host to Caddy for simpler certificate management

Common Mistakes

Adding both reverse_proxy and file_server with no path matcher, expecting them to layer the way Nginx location blocks would.
Trying to add manual SSLCertificateFile-style directives out of habit from Apache/Nginx, when Caddy needs none for standard Let's Encrypt issuance.

Tips

If you later add more than one path split (not just /api/*), reach for Caddy's `handle`/`handle_path` blocks with matchers rather than stacking more bare directives in one block.

Caddyfile Generator