Caddyfile Concepts

    1. Structure
    3. Matchers
    5. Snippets
    7. Environment variables

    The Caddyfile’s structure can be described visually:

    Key points:

    • An optional global options block can be the very first thing in the file.
    • Otherwise, the first line of the Caddyfile is always the address(es) of the site to serve.
    • All directives and matchers must go in a site block. There is no global scope or inheritence across site blocks.
    • If there is only one site block, its curly braces are optional.

    A Caddyfile consists of at least one or more site blocks, which always starts with one or more addresses for the site. Any directives appearing before the address will be confusing to the parser.

    Opening and closing a block is done with curly braces:

    • The open curly brace { must be at the end of its line.

    When there is only one site block, the curly braces (and indentation) are optional. This is for convenience to quickly define a single site, for example, this:

    1. localhost
    3. reverse_proxy /api/* localhost:9001
    4. file_server

    is equivalent to:

    1. localhost {
    2.     reverse_proxy /api/* localhost:9001
    3.     file_server
    4. }

    when you have only a single site block; it’s a matter of preference.

    To configure multiple sites with the same Caddyfile, you must use curly braces around each one to separate their configurations:

    1. example1.com {
    2.     root * /www/example.com
    3.     file_server
    4. }
    6. example2.com {
    7.     reverse_proxy localhost:9000
    8. }

    If a request matches multiple site blocks, the site block with the most specific matching address is chosen. Requests don’t cascade into to other site blocks.

    Directives are keywords which customize how the site is served. For example, a complete file server config might look like this:

    1. localhost
    3. file_server

    Or a reverse proxy:

    1. localhost
    3. reverse_proxy localhost:9000

    In these examples, file_server and reverse_proxy are directives. Directives are the first word on a line in a site block.

    In the second example, localhost:9000 is an argument because it appears on the same line after the directive.

    Subdirectives can appear in directive blocks:

    Here, lb_policy is a subdirective to reverse_proxy (it sets the load balancing policy to use between backends).

    Often, directives expect a certain number of arguments; if a single argument has a value with whitespace, it would be lexed as two separate tokens:

    1. directive abc def

    This could be problematic and return errors or unexpected behavior.

    If abc def is supposed to be the value of a single argument, it needs to be quoted:

    1. directive "abc def"

    Quotes can be escaped if you need to use quotes in quoted tokens, too:

      Inside quoted tokens, all other characters are treated literally, including spaces, tabs, and newlines.

      You can also use a backtick ` to quote tokens:

      1. directive `"foo bar"`

      Backtick strings are convenient when tokens contain quote literals, e.g. JSON text.

      Addresses

      An address always appears at the top of the site block, and is usually the first thing in the Caddyfile.

      These are examples of valid addresses:

      • localhost
      • example.com
      • :443
      • http://example.com
      • localhost:8080
      • [::1]:2015
      • example.com/foo/*
      • *.example.com
      • http://

      Automatic HTTPS is enabled if your site’s address contains a hostname or IP address. This behavior is purely implicit, however, so it never overrides any explicit configuration. For example, if the site’s address is http://example.com, auto-HTTPS will not activate because the scheme is explicitly http://.

      From the address, Caddy can potentially infer the scheme, host, port, and path of your site.

      If you specify a hostname, only requests with a matching Host header will be honored. In other words, if the site address is localhost, then Caddy will not match requests to 127.0.0.1.

      Wildcards (*) may be used, but only to represent precisely one label of the hostname. For example, *.example.com matches foo.example.com but not foo.bar.example.com, and * matches localhost but not example.com. To catch all hosts, omit the host portion of the address.

      If multiple sites share the same definition, you can list all of them together:

      1. localhost:8080, example.com, www.example.com

      or

      Notice how the commas indicate the continuation of addresses.

      By default, a directive that injects an HTTP handler applies to all requests (unless otherwise documented).

      Request matchers can be used to classify requests by a given criteria. This concept originates in the structure, and it’s important to know how to use them in the Caddyfile. With matchers, you can specify exactly which requests a certain directive applies to.

      For directives that support matchers, the first argument after the directive is the matcher token. Here are some examples:

      1. root *           /var/www  # matcher token: *
      2. root /index.html /var/www  # matcher token: /index.html
      3. root @post       /var/www  # matcher token: @post

      Matcher tokens can be omitted entirely to match all requests; for example, * does not need to be given if the next argument does not look like a path matcher.

      Read the page about request matchers to learn more.

      Placeholders

      You can use any Caddy placeholders in the Caddyfile, but for convenience you can also use some equivalent shorthand ones:

      You can define special blocks called snippets by giving them a name surrounded in parentheses:

      1. (redirect) {
      2.     @http {
      3.         scheme http
      4.     }
      5.     redir @http https://{host}{uri}
      6. }

      And then you can reuse this anywhere you need:

      1. import redirect

      The import directive can also be used to include other files in its place. As a special case, it can appear almost anywhere within the Caddyfile.

      Comments

      Comments start with # and proceed until the end of the line:

      1. # Comments can start a line
      2. directive  # or go at the end

      The hash character # cannot appear in the middle of a token (i.e. it must be preceded by a space or appear at the beginning of a line). This allows the use of hashes within URIs or other values without requiring quoting.

      If your configuration relies on environment variables, you can use them in the Caddyfile:

        Environment variables in this form are substituted before parsing begins, so they can expand to empty values, partial tokens, complete tokens, or even multiple tokens and lines.

        If you want to defer the substitution of an environment variable until runtime, you can use the standard placeholders.

        Global options

        A Caddyfile may optionally start with a special block that has no keys, called a global options block:

        If present, it must be the very first block in the config.

        about the global options block.