This tutorial will teach you the basics of the [HTTP Caddyfile](/docs/caddyfile) so that you can quickly and easily produce good-looking, functional site configs.
<asideclass="tip">Caddy serves all sites over HTTPS by default as long as a host or IP is part of the site's address. <ahref="/docs/automatic-https">Automatic HTTPS</a> can be disabled by prefixing the address with <code>http://</code> explicitly.</aside>
That's not particularly exciting, so let's change our static response to a [file server](/docs/caddyfile/directives/file_server) with directory listings enabled:
Save your Caddyfile, then refresh your browser tab. You should either see a list of files or an HTML page if there is an index file in the current directory.
Page loaded at: {<!---->{now | date "Mon Jan 2 15:04:05 MST 2006"}<!---->}
```
Wait a minute. We should see today's date. Why didn't it work? It's because the server hasn't yet been configured to evaluate templates! Easy to fix, just add a line to the Caddyfile so it looks like this:
With Caddy's [templates module](/docs/modules/http.handlers.templates), you can do a lot of useful things with static files, such as including other HTML files, making sub-requests, setting response headers, working with data structures, and more!
It's good practice to compress responses with a quick and modern compression algorithm. Let's enable Gzip and Zstandard support using the [`encode`](/docs/caddyfile/directives/encode) directive:
That's the basic process for getting a semi-advanced, production-ready site up and running!
When you're ready to turn on [automatic HTTPS](/docs/automatic-https), just replace your site's address (`localhost` in our tutorial) with your domain name. See our [HTTPS quick-start guide](/docs/quick-starts/https) for more information.
## Multiple sites
With our current Caddyfile, we can only have the one site definition! Only the first line can be the address(es) of the site, and then all the rest of the file has to be directives for that site.
But it is easy to make it so we can add more sites!
Our Caddyfile so far:
```
localhost
encode zstd gzip
templates
file_server browse
```
is equivalent to this one:
```
localhost {
encode zstd gzip
templates
file_server browse
}
```
except the second one allows us to add more sites.
By wrapping our site block in curly braces `{ }` we are able to define multiple, different sites in the same Caddyfile.
For example:
```
:8080 {
respond "I am 8080"
}
:8081 {
respond "I am 8081"
}
```
When wrapping site blocks in curly braces, only [addresses](/docs/caddyfile/concepts#addresses) appear outside the curly braces and only [directives](/docs/caddyfile/directives) appear inside them.
For multiple sites which share the same configuration, you can add more addresses, for example:
```
:8080, :8081 {
...
}
```
You can then define as many different sites as you want, as long as each address is unique.
We may want to apply some directives only to certain requests. For example, let's suppose we want to have both a file server and a reverse proxy, but we obviously can't do both on every request! Either the file server will write a static file, or the reverse proxy will proxy the request to a backend.
In practice, we may want to use the reverse proxy only for API requests, i.e. requests with a base path of `/api/`. This is easy to do by adding a [matcher token](/docs/caddyfile/matchers#syntax):
There; now the reverse proxy will be prioritized for all requests starting with `/api/`.
The `/api/*` token we just added is called a **matcher token**. You can tell it's a matcher token because it starts with a forward slash `/` and it appears right after the directive (but you can always look it up in the [directive's docs](/docs/caddyfile/directives) to be sure).
Matchers are really powerful. You can name matchers and use them like `@name` to match on more than just the request path! Take a moment to [learn more about matchers](/docs/caddyfile/matchers) before continuing!
