diff --git a/Caddyfile b/Caddyfile index 84fffc5..35de961 100644 --- a/Caddyfile +++ b/Caddyfile @@ -3,15 +3,22 @@ localhost root * src file_server -templates -encode gzip +templates { + extensions { + hitCounter { + style bright_green + pad_digits 6 + } + } +} +encode zstd gzip try_files {path}.html {path} -redir /docs/json /docs/json/ -redir /docs/modules /docs/modules/ -rewrite /docs/json/* /docs/json/index.html +redir /docs/json /docs/json/ +redir /docs/modules /docs/modules/ +rewrite /docs/json/* /docs/json/index.html rewrite /docs/modules/* /docs/modules/index.html -rewrite /docs/* /docs/index.html +rewrite /docs/* /docs/index.html reverse_proxy /api/* localhost:4444 diff --git a/README.md b/README.md index 088718e..d805baa 100644 --- a/README.md +++ b/README.md @@ -6,7 +6,8 @@ This is the source of the Caddy website, [caddyserver.com](https://caddyserver.c ## Requirements -- Caddy 2 (installed in your PATH as `caddy`) +- Caddy v2.7.6 or newer (installed in your PATH as `caddy`) +- To display the retro hit counter (just for fun), the [caddy-hitcounter](https://github.com/mholt/caddy-hitcounter) plugin. ## Quick start diff --git a/new/Caddyfile b/new/Caddyfile new file mode 100644 index 0000000..f0d0ffc --- /dev/null +++ b/new/Caddyfile @@ -0,0 +1,30 @@ +{ + debug +} + +localhost { + file_server + templates { + extensions { + hitCounter { + style bright_green + pad_digits 6 + } + } + } + + try_files {path}.html {path} + + handle_path /temporary-markdown-proxy/* { + reverse_proxy 127.0.0.1:10434 + } +} + +:10434 { + log + bind 127.0.0.1 + root ../src/docs/markdown + uri strip_prefix /docs + try_files {path}.md {path} + file_server +} diff --git a/src/account/create.html b/src/account/create.html index f40eb78..31de297 100644 --- a/src/account/create.html +++ b/src/account/create.html @@ -2,14 +2,14 @@ Create Account - Caddy - {{import "/includes/account/head.html"}} + {{import "/old/includes/account/head.html"}} {{template "account-head"}} - +
- +

Create Account

diff --git a/src/account/index.html b/src/account/index.html index f1d7ec7..e355707 100644 --- a/src/account/index.html +++ b/src/account/index.html @@ -2,14 +2,14 @@ Dashboard - Caddy - {{import "/includes/account/head.html"}} + {{import "/old/includes/account/head.html"}} {{template "account-head"}} - +
- {{include "/includes/account/nav.html"}} + {{include "/old/includes/account/nav.html"}}

Your packagesRegister package

diff --git a/src/account/login.html b/src/account/login.html index abfe73a..59b4dfa 100644 --- a/src/account/login.html +++ b/src/account/login.html @@ -2,14 +2,14 @@ Log In - Caddy - {{import "/includes/account/head.html"}} + {{import "/old/includes/account/head.html"}} {{template "account-head"}} - +
- +

Log In

diff --git a/src/account/logout.html b/src/account/logout.html index ba8ead9..297c814 100644 --- a/src/account/logout.html +++ b/src/account/logout.html @@ -2,9 +2,9 @@ Logout - Caddy - {{import "/includes/account/head.html"}} + {{import "/old/includes/account/head.html"}} {{template "account-head"}} - + Logging out... diff --git a/src/account/register-package.html b/src/account/register-package.html index cf07d3d..63977d2 100644 --- a/src/account/register-package.html +++ b/src/account/register-package.html @@ -2,13 +2,13 @@ Register Package - Caddy - {{import "/includes/account/head.html"}} + {{import "/old/includes/account/head.html"}} {{template "account-head"}} - +
- {{include "/includes/account/nav.html"}} + {{include "/old/includes/account/nav.html"}}
diff --git a/src/account/reset-password.html b/src/account/reset-password.html index 4c466c5..6e051f3 100644 --- a/src/account/reset-password.html +++ b/src/account/reset-password.html @@ -2,14 +2,14 @@ Reset Password - Caddy - {{import "/includes/account/head.html"}} + {{import "/old/includes/account/head.html"}} {{template "account-head"}} - +
- +

Reset Password

@@ -22,7 +22,7 @@
- +

Reset Password

diff --git a/src/account/verify.html b/src/account/verify.html index 132d152..3edb3b5 100644 --- a/src/account/verify.html +++ b/src/account/verify.html @@ -2,14 +2,14 @@ Confirm Account - Caddy - {{import "/includes/account/head.html"}} + {{import "/old/includes/account/head.html"}} {{template "account-head"}} - +
- +

Confirm Account

diff --git a/src/business.html b/src/business.html deleted file mode 100644 index 96c0e31..0000000 --- a/src/business.html +++ /dev/null @@ -1,48 +0,0 @@ - - - - Caddy for Business - {{import "/includes/head.html"}} - {{template "head"}} - - - - - -
-
-
- -
a project
-
- {{include "/includes/header-nav.html"}} -
- -

Ready for business

- -
-
-
-

Need help with something?

-

- Most users should participate in our community forum to help others and ask questions. -

-

- The only price for this help is to put some effort into your question and say thank you. 😃 -

-
-
-

Support and development for businesses

-

- We highly recommend that companies using Caddy get a support plan and contract any related development work with our exclusive partner Ardan Labs. Contact us to get started: -

- Email business@caddyserver.com -
-
-
-
- - {{include "/includes/footer.html"}} - - - diff --git a/src/docs/index.html b/src/docs/index.html index 98960de..e0c28ae 100644 --- a/src/docs/index.html +++ b/src/docs/index.html @@ -8,15 +8,15 @@ {{$title}} — Caddy Documentation - {{import "/includes/docs/head.html"}} + {{import "/old/includes/docs/head.html"}} {{template "docs-head"}} - {{include "/includes/docs/header.html"}} + {{include "/old/includes/docs/header.html"}}
- {{include "/includes/docs/nav.html"}} + {{include "/old/includes/docs/nav.html"}}
@@ -26,6 +26,6 @@
- {{include "/includes/footer.html"}} + {{include "/old/includes/footer.html"}} diff --git a/src/docs/json/index.html b/src/docs/json/index.html index 9ecea52..7aec582 100644 --- a/src/docs/json/index.html +++ b/src/docs/json/index.html @@ -2,17 +2,17 @@ JSON Config Structure - Caddy Documentation - {{import "/includes/docs/head.html"}} + {{import "/old/includes/docs/head.html"}} {{template "docs-head"}} - - - - + + + + - {{include "/includes/docs/header.html"}} + {{include "/old/includes/docs/header.html"}}
- {{include "/includes/docs/nav.html"}} + {{include "/old/includes/docs/nav.html"}}
@@ -21,16 +21,16 @@
- {{include "/includes/docs/renderbox.html"}} - {{include "/includes/docs/details.html"}} + {{include "/old/includes/docs/renderbox.html"}} + {{include "/old/includes/docs/details.html"}}
- {{include "/includes/docs/hovercard.html"}} + {{include "/old/includes/docs/hovercard.html"}} - {{include "/includes/footer.html"}} + {{include "/old/includes/footer.html"}} diff --git a/src/docs/markdown/api-tutorial.md b/src/docs/markdown/api-tutorial.md index 99c428f..a9ceea1 100644 --- a/src/docs/markdown/api-tutorial.md +++ b/src/docs/markdown/api-tutorial.md @@ -153,7 +153,7 @@ You should see: diff --git a/src/docs/markdown/api.md b/src/docs/markdown/api.md index 4ed2700..f54037b 100644 --- a/src/docs/markdown/api.md +++ b/src/docs/markdown/api.md @@ -4,7 +4,7 @@ title: "API" # API -Caddy is configured through an administration endpoint which can be accessed via HTTP using a [REST ](https://en.wikipedia.org/wiki/Representational_state_transfer) API. You can [configure this endpoint](/docs/json/admin/) in your Caddy config. +Caddy is configured through an administration endpoint which can be accessed via HTTP using a [REST ](https://en.wikipedia.org/wiki/Representational_state_transfer) API. You can [configure this endpoint](/docs/json/admin/) in your Caddy config. **Default address: `localhost:2019`** @@ -254,7 +254,7 @@ This section is for all `/config/` endpoints. It is experimental and subject to -Caddy's config API provides [ACID guarantees ](https://en.wikipedia.org/wiki/ACID) for individual requests, but changes that involve more than a single request are subject to collisions or data loss if not properly synchronized. +Caddy's config API provides [ACID guarantees ](https://en.wikipedia.org/wiki/ACID) for individual requests, but changes that involve more than a single request are subject to collisions or data loss if not properly synchronized. For example, two clients may `GET /config/foo` at the same time, make an edit within that scope (config path), then call `POST|PUT|PATCH|DELETE /config/foo/...` at the same time to apply their changes, resulting in a collision: either one will overwrite the other, or the second might leave the config in an unintended state since it was applied to a different version of the config than it was prepared against. This is because the changes are not aware of each other. diff --git a/src/docs/markdown/automatic-https.md b/src/docs/markdown/automatic-https.md index 55e0f7f..3855fc8 100644 --- a/src/docs/markdown/automatic-https.md +++ b/src/docs/markdown/automatic-https.md @@ -39,7 +39,7 @@ Here's a 28-second video showing how it works: - Caddy serves IP addresses and local/internal hostnames over HTTPS using self-signed certificates that are automatically trusted locally (if permitted). - Examples: `localhost`, `127.0.0.1` -- Caddy serves public DNS names over HTTPS using certificates from a public ACME CA such as [Let's Encrypt ](https://letsencrypt.org) or [ZeroSSL ](https://zerossl.com). +- Caddy serves public DNS names over HTTPS using certificates from a public ACME CA such as [Let's Encrypt ](https://letsencrypt.org) or [ZeroSSL ](https://zerossl.com). - Examples: `example.com`, `sub.example.com`, `*.example.com` Caddy keeps all managed certificates renewed and redirects HTTP (default port `80`) to HTTPS (default port `443`) automatically. @@ -89,7 +89,7 @@ Any of the following will prevent automatic HTTPS from being activated, either i **Special cases:** -- Domains ending in `.ts.net` will not be managed by Caddy. Instead, Caddy will automatically attempt to get these certificates at handshake-time from the locally-running [Tailscale ](https://tailscale.com) instance. This requires that [HTTPS is enabled in your Tailscale account ](https://tailscale.com/kb/1153/enabling-https/) and the Caddy process must either be running as root, or you must configure `tailscaled` to give your Caddy user [permission to fetch certificates](https://github.com/caddyserver/caddy/pull/4541#issuecomment-1021568348). +- Domains ending in `.ts.net` will not be managed by Caddy. Instead, Caddy will automatically attempt to get these certificates at handshake-time from the locally-running [Tailscale ](https://tailscale.com) instance. This requires that [HTTPS is enabled in your Tailscale account ](https://tailscale.com/kb/1153/enabling-https/) and the Caddy process must either be running as root, or you must configure `tailscaled` to give your Caddy user [permission to fetch certificates](https://github.com/caddyserver/caddy/pull/4541#issuecomment-1021568348). ## Effects @@ -126,7 +126,7 @@ Caddy uses HTTPS automatically for all sites with a host (domain, IP, or hostnam To serve non-public sites over HTTPS, Caddy generates its own certificate authority (CA) and uses it to sign certificates. The trust chain consists of a root and intermediate certificate. Leaf certificates are signed by the intermediate. They are stored in [Caddy's data directory](/docs/conventions#data-directory) at `pki/authorities/local`. -Caddy's local CA is powered by [Smallstep libraries ](https://smallstep.com/certificates/). +Caddy's local CA is powered by [Smallstep libraries ](https://smallstep.com/certificates/). Local HTTPS does not use ACME nor does it perform any DNS validation. It works only on the local machine and is trusted only where the CA's root certificate is installed. @@ -158,7 +158,7 @@ Unlike the root certificate, intermediate certificates have a much shorter lifet To test or experiment with your Caddy configuration, make sure you [change the ACME endpoint](/docs/modules/tls.issuance.acme#ca) to a staging or development URL, otherwise you are likely to hit rate limits which can block your access to HTTPS for up to a week, depending on which rate limit you hit. -One of Caddy's default CAs is [Let's Encrypt ](https://letsencrypt.org/), which has a [staging endpoint ](https://letsencrypt.org/docs/staging-environment/) that is not subject to the same [rate limits ](https://letsencrypt.org/docs/rate-limits/): +One of Caddy's default CAs is [Let's Encrypt ](https://letsencrypt.org/), which has a [staging endpoint ](https://letsencrypt.org/docs/staging-environment/) that is not subject to the same [rate limits ](https://letsencrypt.org/docs/rate-limits/): ``` https://acme-staging-v02.api.letsencrypt.org/directory @@ -166,7 +166,7 @@ https://acme-staging-v02.api.letsencrypt.org/directory ## ACME challenges -Obtaining a publicly-trusted TLS certificate requires validation from a publicly-trusted, third-party authority. These days, this validation process is automated with the [ACME protocol ](https://tools.ietf.org/html/rfc8555), and can be performed one of three ways ("challenge types"), described below. +Obtaining a publicly-trusted TLS certificate requires validation from a publicly-trusted, third-party authority. These days, this validation process is automated with the [ACME protocol ](https://tools.ietf.org/html/rfc8555), and can be performed one of three ways ("challenge types"), described below. The first two challenge types are enabled by default. If multiple challenges are enabled, Caddy chooses one at random to avoid accidental dependence on a particular challenge. Over time, it learns which challenge type is most successful and will begin to prefer it first, but will fall back to other available challenge types if necessary. @@ -245,7 +245,7 @@ Here's what happens if there's an error obtaining or renewing a certificate: - Maximum of 1 day between attempts - For up to 30 days -During retries with Let's Encrypt, Caddy switches to their [staging environment ](https://letsencrypt.org/docs/staging-environment/) to avoid rate limit concerns. This isn't a perfect strategy, but in general it's helpful. +During retries with Let's Encrypt, Caddy switches to their [staging environment ](https://letsencrypt.org/docs/staging-environment/) to avoid rate limit concerns. This isn't a perfect strategy, but in general it's helpful. ACME challenges take at least a few seconds, and internal rate limiting helps mitigate accidental abuse. Caddy uses internal rate limiting in addition to what you or the CA configure so that you can hand Caddy a platter with a million domain names and it will gradually -- but as fast as it can -- obtain certificates for all of them. Caddy's internal rate limit is currently 10 attempts per ACME account per 10 seconds. @@ -255,7 +255,7 @@ To avoid leaking resources, Caddy aborts in-flight tasks (including ACME transac Caddy is the first (and so far only) server to support fully-redundant, automatic failover to other CAs in the event it cannot successfully get a certificate. -By default, Caddy enables two ACME-compatible CAs: [**Let's Encrypt** ](https://letsencrypt.org) and [**ZeroSSL** ](https://zerossl.com). If Caddy cannot get a certificate from Let's Encrypt, it will try with ZeroSSL; if both fail, it will backoff and retry again later. In your config, you can customize which issuers Caddy uses to obtain certificates, either universally or for specific names. +By default, Caddy enables two ACME-compatible CAs: [**Let's Encrypt** ](https://letsencrypt.org) and [**ZeroSSL** ](https://zerossl.com). If Caddy cannot get a certificate from Let's Encrypt, it will try with ZeroSSL; if both fail, it will backoff and retry again later. In your config, you can customize which issuers Caddy uses to obtain certificates, either universally or for specific names. ## Storage @@ -277,4 +277,4 @@ If using the Caddyfile, Caddy takes site names literally with regards to the cer Wildcard certificates represent a wide degree of authority and should only be used when you have so many subdomains that managing individual certificates for them would strain the PKI or cause you to hit CA-enforced rate limits. -**Note:** [Let's Encrypt requires ](https://letsencrypt.org/docs/challenge-types/) the [DNS challenge](#dns-challenge) to obtain wildcard certificates. +**Note:** [Let's Encrypt requires ](https://letsencrypt.org/docs/challenge-types/) the [DNS challenge](#dns-challenge) to obtain wildcard certificates. diff --git a/src/docs/markdown/caddyfile/directives/log.md b/src/docs/markdown/caddyfile/directives/log.md index b420b4b..9872f71 100644 --- a/src/docs/markdown/caddyfile/directives/log.md +++ b/src/docs/markdown/caddyfile/directives/log.md @@ -147,7 +147,7 @@ The **format** subdirective lets you customize how logs get encoded (formatted). @@ -440,7 +440,7 @@ log { } ``` - To write the access logs for a particular subdomain to two different files, with different formats (one with [`transform-encoder` plugin ](https://github.com/caddyserver/transform-encoder) and the other with [`json`](#json)). + To write the access logs for a particular subdomain to two different files, with different formats (one with [`transform-encoder` plugin ](https://github.com/caddyserver/transform-encoder) and the other with [`json`](#json)). This works by overriding the logger name as `foo` in the site block, then including the access logs produced by that logger in the two loggers in global options with `include http.log.access.foo`: diff --git a/src/docs/markdown/caddyfile/directives/reverse_proxy.md b/src/docs/markdown/caddyfile/directives/reverse_proxy.md index 969e695..4a46446 100644 --- a/src/docs/markdown/caddyfile/directives/reverse_proxy.md +++ b/src/docs/markdown/caddyfile/directives/reverse_proxy.md @@ -748,7 +748,7 @@ reverse_proxy 10.0.0.1:443 { -[Strip a path prefix](/docs/caddyfile/directives/handle_path) before proxying; but be aware of the [subfolder problem ](https://caddy.community/t/the-subfolder-problem-or-why-cant-i-reverse-proxy-my-app-into-a-subfolder/8575): +[Strip a path prefix](/docs/caddyfile/directives/handle_path) before proxying; but be aware of the [subfolder problem ](https://caddy.community/t/the-subfolder-problem-or-why-cant-i-reverse-proxy-my-app-into-a-subfolder/8575): ```caddy-d handle_path /prefix/* { diff --git a/src/docs/markdown/caddyfile/directives/tls.md b/src/docs/markdown/caddyfile/directives/tls.md index e15f2ee..017a80f 100644 --- a/src/docs/markdown/caddyfile/directives/tls.md +++ b/src/docs/markdown/caddyfile/directives/tls.md @@ -94,17 +94,17 @@ Keep in mind that Let's Encrypt may send you emails about your certificate neari - `secp384r1` - `secp521r1` -- **alpn** is the list of values to advertise in the [ALPN extension ](https://developer.mozilla.org/en-US/docs/Glossary/ALPN) of the TLS handshake. +- **alpn** is the list of values to advertise in the [ALPN extension ](https://developer.mozilla.org/en-US/docs/Glossary/ALPN) of the TLS handshake. - **load** specifies a list of folders from which to load PEM files that are certificate+key bundles. -- **ca** changes the ACME CA endpoint. This is most often used to set [Let's Encrypt's staging endpoint ](https://letsencrypt.org/docs/staging-environment/) when testing, or an internal ACME server. (To change this value for the whole Caddyfile, use the `acme_ca` [global option](/docs/caddyfile/options) instead.) +- **ca** changes the ACME CA endpoint. This is most often used to set [Let's Encrypt's staging endpoint ](https://letsencrypt.org/docs/staging-environment/) when testing, or an internal ACME server. (To change this value for the whole Caddyfile, use the `acme_ca` [global option](/docs/caddyfile/options) instead.) - **ca_root** specifies a PEM file that contains a trusted root certificate for the ACME CA endpoint, if not in the system trust store. - **key_type** is the type of key to use when generating CSRs. Only set this if you have a specific requirement. -- **dns** enables the [DNS challenge](/docs/automatic-https#dns-challenge) using the specified provider plugin, which must be plugged in from one of the [`caddy-dns` ](https://github.com/caddy-dns) repositories. Each provider plugin may have their own syntax following their name; refer to their docs for details. Maintaining support for each DNS provider is a community effort. [Learn how to enable the DNS challenge for your provider at our wiki.](https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148) +- **dns** enables the [DNS challenge](/docs/automatic-https#dns-challenge) using the specified provider plugin, which must be plugged in from one of the [`caddy-dns` ](https://github.com/caddy-dns) repositories. Each provider plugin may have their own syntax following their name; refer to their docs for details. Maintaining support for each DNS provider is a community effort. [Learn how to enable the DNS challenge for your provider at our wiki.](https://caddy.community/t/how-to-use-dns-provider-modules-in-caddy-2/8148) - **propagation_timeout** is a [duration value](/docs/conventions#durations) that sets the maximum time to wait for the DNS TXT records to appear when using the DNS challenge. Set to `-1` to disable propagation checks. Default 2 minutes. @@ -114,13 +114,13 @@ Keep in mind that Let's Encrypt may send you emails about your certificate neari - **dns_challenge_override_domain** overrides the domain to use for the DNS challenge. This is to delegate the challenge to a different domain. - You may want to use this if your primary domain's DNS provider does not have a [DNS plugin ](https://github.com/caddy-dns) available. You can instead add a `CNAME` record with subdomain `_acme-challenge` to your primary domain, pointing to a secondary domain for which you _do_ have a plugin. + You may want to use this if your primary domain's DNS provider does not have a [DNS plugin ](https://github.com/caddy-dns) available. You can instead add a `CNAME` record with subdomain `_acme-challenge` to your primary domain, pointing to a secondary domain for which you _do_ have a plugin. When ACME issuers try to solve the DNS challenge for your primary domain, they will then follow the `CNAME` to your secondary domain to find the `TXT` record. - **resolvers** customizes the DNS resolvers used when performing the DNS challenge; these take precedence over system resolvers or any default ones. If set here, the resolvers will propagate to all configured certificate issuers. - This is typically a list of IP addresses. For example, to use [Google Public DNS ](https://developers.google.com/speed/public-dns): + This is typically a list of IP addresses. For example, to use [Google Public DNS ](https://developers.google.com/speed/public-dns): ```caddy-d resolvers 8.8.8.8 8.8.4.4 @@ -230,13 +230,13 @@ Obtains certificates using the ACME protocol. Note that `acme` is a default issu - **dns_challenge_override_domain** overrides the domain to use for the DNS challenge. This is to delegate the challenge to a different domain. - You may want to use this if your primary domain's DNS provider does not have a [DNS plugin ](https://github.com/caddy-dns) available. You can instead add a `CNAME` record with subdomain `_acme-challenge` to your primary domain, pointing to a secondary domain for which you _do_ have a plugin. + You may want to use this if your primary domain's DNS provider does not have a [DNS plugin ](https://github.com/caddy-dns) available. You can instead add a `CNAME` record with subdomain `_acme-challenge` to your primary domain, pointing to a secondary domain for which you _do_ have a plugin. When ACME issuers try to solve the DNS challenge for your primary domain, they will then follow the `CNAME` to your secondary domain to find the `TXT` record. - **resolvers** customizes the DNS resolvers used when performing the DNS challenge; these take precedence over system resolvers or any default ones. If set here, the resolvers will propagate to all configured certificate issuers. - This is typically a list of IP addresses. For example, to use [Google Public DNS ](https://developers.google.com/speed/public-dns): + This is typically a list of IP addresses. For example, to use [Google Public DNS ](https://developers.google.com/speed/public-dns): ```caddy-d resolvers 8.8.8.8 8.8.4.4 @@ -298,7 +298,7 @@ These manager modules come standard with the `tls` directive: #### tailscale -Get certificates from a locally-running [Tailscale ](https://tailscale.com) instance. [HTTPS must be enabled in your Tailscale account](https://tailscale.com/kb/1153/enabling-https/) (or your open source [Headscale server ](https://github.com/juanfont/headscale)); and the Caddy process must either be running as root, or you must configure `tailscaled` to give your Caddy user [permission to fetch certificates](https://github.com/caddyserver/caddy/pull/4541#issuecomment-1021568348). +Get certificates from a locally-running [Tailscale ](https://tailscale.com) instance. [HTTPS must be enabled in your Tailscale account](https://tailscale.com/kb/1153/enabling-https/) (or your open source [Headscale server ](https://github.com/juanfont/headscale)); and the Caddy process must either be running as root, or you must configure `tailscaled` to give your Caddy user [permission to fetch certificates](https://github.com/caddyserver/caddy/pull/4541#issuecomment-1021568348). _**NOTE: This is usually unnecessary!** Caddy automatically uses Tailscale for all `*.ts.net` domains without any extra configuration._ diff --git a/src/docs/markdown/caddyfile/options.md b/src/docs/markdown/caddyfile/options.md index abf7836..fd932cf 100644 --- a/src/docs/markdown/caddyfile/options.md +++ b/src/docs/markdown/caddyfile/options.md @@ -323,7 +323,7 @@ Skips the attempts to install the local CA's root into the system trust store, a ##### `acme_ca` -Specifies the URL to the ACME CA's directory. It is strongly recommended to set this to Let's Encrypt's [staging endpoint ](https://letsencrypt.org/docs/staging-environment/) for testing or development. Default: ZeroSSL and Let's Encrypt's production endpoints. +Specifies the URL to the ACME CA's directory. It is strongly recommended to set this to Let's Encrypt's [staging endpoint ](https://letsencrypt.org/docs/staging-environment/) for testing or development. Default: ZeroSSL and Let's Encrypt's production endpoints. Note that a globally-configured ACME CA may not apply to all sites; see the [hostname requirements](/docs/automatic-https#hostname-requirements) for using the default ACME issuer(s). @@ -642,7 +642,7 @@ Events typically include a metadata payload. The best way to learn about events Binds an event handler to the named event. Specify the name of the event handler module, followed by its configuration. -For example, to run a command after a certificate is obtained ([third-party plugin ](https://github.com/mholt/caddy-events-exec) required), with a part of the event payload being passed to the script using a placeholder: +For example, to run a command after a certificate is obtained ([third-party plugin ](https://github.com/mholt/caddy-events-exec) required), with a part of the event payload being passed to the script using a placeholder: ```caddy { @@ -656,7 +656,7 @@ For example, to run a command after a certificate is obtained ([third-party plug These standard events are emitted by Caddy: -- [`tls` events ](https://github.com/caddyserver/certmagic#events) +- [`tls` events ](https://github.com/caddyserver/certmagic#events) - [`reverse_proxy` events](/docs/caddyfile/directives/reverse_proxy#events) Plugins may also emit events, so check their documentation for details. diff --git a/src/docs/markdown/conventions.md b/src/docs/markdown/conventions.md index 0120108..2b4b932 100644 --- a/src/docs/markdown/conventions.md +++ b/src/docs/markdown/conventions.md @@ -65,7 +65,7 @@ unix//path/to/socket|0200 @@ -78,7 +78,7 @@ Caddy's configuration supports the use of _placeholders_ (variables). Using plac @@ -98,7 +98,7 @@ Placeholder | Description `{system.arch}` | The system's architecture `{system.wd}` | The current working directory `{time.now}` | The current time as a Go Time struct -`{time.now.http}` | The current time in the format used in [HTTP headers ](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) +`{time.now.http}` | The current time in the format used in [HTTP headers ](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified) `{time.now.unix}` | The current time as a unix timestamp in seconds `{time.now.unix_ms}` | The current time as a unix timestamp in milliseconds `{time.now.common_log}` | The current time in Common Log Format diff --git a/src/docs/markdown/extending-caddy.md b/src/docs/markdown/extending-caddy.md index f036ff9..40e6036 100644 --- a/src/docs/markdown/extending-caddy.md +++ b/src/docs/markdown/extending-caddy.md @@ -9,8 +9,8 @@ Caddy is easy to extend because of its modular architecture. Most kinds of Caddy **Prerequisites:** - Basic understanding of [Caddy's architecture](/docs/architecture) - Go language proficiency -- [`go` ](https://golang.org/doc/install) -- [`xcaddy` ](https://github.com/caddyserver/xcaddy) +- [`go` ](https://golang.org/doc/install) +- [`xcaddy` ](https://github.com/caddyserver/xcaddy) ## Quick Start diff --git a/src/docs/markdown/logging.md b/src/docs/markdown/logging.md index fad1a21..414e0ed 100644 --- a/src/docs/markdown/logging.md +++ b/src/docs/markdown/logging.md @@ -92,7 +92,7 @@ You can see how the structured log is much more useful and contains much more in Because the logs are structured and strongly-typed, they can be encoded into any format. So if you don't want to work with JSON, logs can be encoded into any other representation. Caddy supports others through [log encoder modules](/docs/json/logging/logs/encoder/), and even more can be added. -**Most importantly** in the distinction between structured logs and legacy formats, with a performance penalty a structured log [can be transformed into the legacy Common Log Format ](https://github.com/caddyserver/transform-encoder), but not the other way around. It is non-trivial (or at least inefficient) to go from CLF to structured formats, and impossible considering the lack of information. +**Most importantly** in the distinction between structured logs and legacy formats, with a performance penalty a structured log [can be transformed into the legacy Common Log Format ](https://github.com/caddyserver/transform-encoder), but not the other way around. It is non-trivial (or at least inefficient) to go from CLF to structured formats, and impossible considering the lack of information. In essence, efficient, structured logging generally promotes these philosophies: diff --git a/src/docs/modules/index.html b/src/docs/modules/index.html index 7ffb20d..12899c2 100644 --- a/src/docs/modules/index.html +++ b/src/docs/modules/index.html @@ -2,17 +2,17 @@ Modules - Caddy Documentation - {{import "/includes/docs/head.html"}} + {{import "/old/includes/docs/head.html"}} {{template "docs-head"}} - - - - + + + + - {{include "/includes/docs/header.html"}} + {{include "/old/includes/docs/header.html"}}
- {{include "/includes/docs/nav.html"}} + {{include "/old/includes/docs/nav.html"}}
@@ -42,8 +42,8 @@
- {{include "/includes/docs/renderbox.html"}} - {{include "/includes/docs/details.html"}} + {{include "/old/includes/docs/renderbox.html"}} + {{include "/old/includes/docs/details.html"}}
@@ -51,7 +51,7 @@
- {{include "/includes/docs/hovercard.html"}} - {{include "/includes/footer.html"}} + {{include "/old/includes/docs/hovercard.html"}} + {{include "/old/includes/footer.html"}} diff --git a/src/download.html b/src/download.html index 43a7025..cb25d89 100644 --- a/src/download.html +++ b/src/download.html @@ -2,21 +2,21 @@ Download Caddy - {{import "/includes/head.html"}} + {{import "/old/includes/head.html"}} {{template "head"}} - - - - + + + +
- -
a project
+ +
a project
- {{include "/includes/header-nav.html"}} + {{include "/old/includes/header-nav.html"}}
@@ -89,6 +89,6 @@
- {{include "/includes/footer.html"}} + {{include "/old/includes/footer.html"}} diff --git a/src/features.html b/src/features.html new file mode 100644 index 0000000..be40fda --- /dev/null +++ b/src/features.html @@ -0,0 +1,1726 @@ + + + + All features of the Caddy Web Server + {{import "/includes/head.html"}} + {{template "head" .}} + + + + +
+ {{include "/includes/header.html" "dark-header"}} + +
+
+

+ All features +
+ You might want to sit down for this. +
+

+
+
+
+ +
+ +
+
+
+ Features in this color are provided by optional plugins. +
+ +

+ Overview +

+

+ Caddy is essentially a configuration management system that can run various apps like an HTTP server, TLS certificate manager, PKI facilities, and more. It can be extended with plugins known as config modules. +

+

+ Caddy sports a flexible and powerful HTTP reverse proxy, on-line configuration API, and a robust, production-ready static file server, and serves all sites over HTTPS by default with automagic TLS certificates. +

+ +

Overall program technical specifications

+ +
+
+

Language

+
+ The language choice is crucial for a web server. Language impacts development speed and ease, performance, testing, deployment complexity, ecosystem reliability, dependencies, tooling, error handling and reliability, and much, much more. Go offers strong advantages in all these areas, allowing for rapid development, robust production performance, and high scalability. +
+
+ Go +
+
+
+

Memory safety guarantees

+
+ Most servers (NGINX, Apache, HAProxy, etc.) and their dependencies are written in C, which are vulnerable to catastrophic memory safety bugs (such as buffer overflows) like Heartbleed. Go programs like Caddy are impervious to a whole class of security vulnerabilities. +
+
+ Strong +
+
+
+

Build artifacts

+
+ Caddy compiles directly to native CPU instructions. There is no interpreter required; and many instructions are architecture-optimized. Static binaries are also more secure because there is no dynamic linking. +
+
+ Platform-native static binary +
+
+
+

Runtime dependencies

+
+ Caddy is statically compiled. Dynamically-linked applications can easily break in production and may be less secure as shared executable resources are loaded from various places around the system. Generally, Caddy binaries do not necessarily require external libraries — not even libc. +
+
+ None +
+
+
+

Compile time

+
+ On consumer hardware, standard Caddy builds compile in just a few seconds. This is crucial for rapid iteration, plugin development, and low-cost deployments. Other servers written in C/C++ can take several minutes. +
+
+ ~30 seconds cold build,
~2 seconds hot +
+
+
+

Deployment environments

+
+ Caddy can go practically anywhere and be deployed a variety of ways. In general, upgrading is as simple as replacing the binary. +
+
    +
  • Command line interface
    • +
  • System service
    • +
  • Containers
    • +
  • Kubernetes
    • +
  • Embedded
    • +
+
+
+

Supply chain and releases

+
+ Go modules verify the integrity of our dependencies and we cryptographically sign our release artifacts so you know what you can trust. +
+
+ Cryptographically verified +
+
+
+

Operating systems

+
+ Caddy runs on every major platform for which Go compiles. +
+
    +
  • Linux
    • +
  • Windows
    • +
  • macOS
    • +
  • FreeBSD
    • +
  • OpenBSD
    • +
  • NetBSD
    • +
  • Android
    • +
+
+
+

Microarchitectures

+
+ Run Caddy with native code on numerous CPU platforms. +
+
    +
  • x86 (i386, i686)
    • +
  • x86-64 (AMD64)
    • +
  • ARM
    • +
  • ARM 64 (AArch64)
    • +
  • MIPS
    • +
  • MIPS64[LE]
    • +
  • PPC64[LE]
    • +
  • RISCV64
    • +
  • S390X
    • +
  • Apple Silicon (Apple ARM; M1, M2, etc.)
    • +
+
+
+

Regular expression engine

+
+ Caddy's regular expression language is based on the Thompson NFA and has numerous performance improvements over PCRE used by other web servers. It guarantees the runtime cost increases linearly instead of exponentially. This is ideal when evaluating untrusted input. +

+ RE2 Syntax +

+
+
+ RE2 +
+
+
+

Concurrency model

+
+ Go's runtime optimizes scheduled CPU time in smarter ways than the operating system can using lightweight user-space threads called goroutines. Caddy utilizes all CPU cores and easily handles hundreds of thousands of requests per second. +
+
+ Goroutines (epoll + kqueue) +
+
+
+

Plugin model

+
+ Caddy can be extended by compile-time plugins, which compile as native code, in a way that cannot be broken during deployments or by system upgrades. With no IPC or RPC calls, Caddy extensions perform equally well with native code. +
+
+ Compile-time static +
+
+
+ +

High-level capabilities

+ +
+
+

Configuration changes

+
+ With zero-downtime graceful reloads, Caddy's configuration can be changed while it is running. It's programmable/scriptable for powerful automation. +
+
    +
  • RESTful HTTP API
    • +
  • Config files
    • +
  • Secure remote access
    • + +
+
+
+

App modules

+
+ Top-level configuration structures are called app modules, or Caddy apps. They provide the bulk of Caddy's functionality. Anyone can write app modules, and Caddy comes with several standard apps built-in. +
+
    +
  • HTTP
    • +
  • TLS
    • +
  • PKI
    • +
  • Events
    • +
  • Raw TCP & UDP
    • +
  • SSH
    • +
  • PHP
    • +
  • Dynamic DNS
    • +
  • Security
    • +
  • Process supervision
    • +
  • Profiling
    • +
+
+
+

Logs

+
+ All Caddy modules use Caddy's centralized logging facilities. Caddy's logging can be configured as to format, verbosity, output, and more. +
+
    +
  • Leveled
    • +
  • Structured
    • +
  • High efficiency, zero-allocation
    • +
  • Extensible
    • +
  • Delete, filter, redact, and censor fields
    • +
  • IP masking
    • +
  • Hash values
    • +
  • Regex replacement
    • +
+
+
+

Storage

+
+ Assets and state, including certificates and OCSP staples, are stored in configurable storage backends. In fact, multiple instances of Caddy configured with the same storage are considered part of a cluster and can coordinate automatically. +
+
    +
  • File system
    • +
  • Embedded (in-memory)
    • +
  • Postgres
    • +
  • Redis
    • +
  • Vault
    • +
  • Consul
    • +
+
+
+
+
+ + + + + + +
+
+

+ Command line interface +

+

+ Caddy's CLI is not only useful—it's helpful. While most server CLIs merely run the process and reload config, Caddy's CLI goes the extra lightyear to help make administering your modern web server a breeze. +

+

+ Plugins can register their own subcommands to extend Caddy's CLI. +

+ +
+
+

Command help

+
+ If you misspell a command or flag, miss an argument, or don't know the subcommand, help text is automatically printed. You can also access overall command help or subcommand help with caddy help or -h. +
+
+ Built-in, automatic (man pages can also be generated) +
+
+
+

Admin API wrappers

+
+ Several subcommands use administration API endpoints for use with the CLI to help you perform common tasks like loading config from files or stopping the server. +
+
    +
  • Adapt config to JSON
    • +
  • Start the server, optionally with config
    • +
  • Gracefully reload configuration
    • +
  • Stop the server
    • +
+
+
+

Binary utilities

+
+ Since custom builds of Caddy are so common, several commands exist to help you manage and get detailed information about your build. +
+
    +
  • Detailed build metadata
    • +
  • List installed config modules
    • +
  • List dependencies
    • +
  • Add and remove plugin packages
    • +
  • Print the version
    • +
  • Upgrade the Caddy binary
    • +
+
+
+

Configuration utilities

+
+ If you choose to use configuration files, Caddy's CLI helps you manage them. +
+
    +
  • Format Caddyfile
    • +
  • Validate configuration
    • +
  • List dependencies
    • +
  • Add and remove plugin packages
    • +
  • Print the version
    • +
+
+
+

Module utilities

+
+ Modules may register their own subcommands to provide common functionality that can be utilized without a config document. +
+
    +
  • Static file server
    • +
  • HTTP reverse proxy
    • +
  • Static HTTP responses (templateable)
    • +
  • Storage import/export (backup/restore)
    • +
  • Hash password for use with HTTP basic auth
    • +
  • Export file browse template
    • +
+
+
+

Integration utilities

+
+ Several subcommands can help you integrate Caddy into your shell environment. +
+
    +
  • Generate shell completion script
    • +
  • Print the environment
    • +
  • Generate man pages
    • +
  • Install Caddy-managed root CA into trust stores
    • +
  • Remove Caddy-managed root CA from trust stores
    • +
+
+
+

System signals

+
+ Caddy has support for common operating system signals/interrupts, with subtle differences in behavior for each one. +

+ Signal documentation +

+
+
    +
  • INT (graceful stop)
    • +
  • QUIT
    • +
  • TERM
    • +
+
+
+

Exit codes

+
+ Whether Caddy exits successfully or with an error, the exit code can give a hint to your process supervisor or script how to handle that. +
+
+
+ +
+
+ + +
+
+

+ Configuration +

+

+ We've designed Caddy so that its configuration not only provides access to features, but it IS a feature in and of itself. +

+

+ No more quibbling over which config file format is the best: use whatever you want! Caddy's config adapters allow you to use whatever config format you prefer. +

+
+
+

Native config format

+
+ Caddy's native configuration format is ubiquitous: it has tooling in nearly every operating system, platform, programming language, and API ecosystem. Almost all other formats can be translated down into JSON, which balances human readability and programmability. You'll find it a powerful ally of your web server. +
+
+ JSON +
+
+
+

Config adapters

+
+ You can always write your config in another format and with config adapters, Caddy will implicitly translate it into JSON for you so you can work with what you like. +
+
    +
  • Caddyfile
    • +
  • JSON 5
    • +
  • JSON-C
    • +
  • NGINX Conf
    • +
  • YAML
    • +
  • CUE
    • +
  • TOML
    • +
  • HCL
    • +
  • Dhall
    • +
  • MySQL
    • +
+
+
+

Human-friendly config

+
+ The Caddyfile is most users' favorite way to write their web server config by hand because its syntax is forgiving while also being designed with a structure that makes it easy to read and write. It is translated to JSON automatically. +
+
+ Caddyfile +
+
+
+

Export

+
+ Caddy's administration API allows you to have runtime access to the current configuration in JSON format with a simple GET request. +
+
+
+

Config API

+
+ Caddy receives its configuration through an API endpoint, which can accept JSON or any other format it has a config adapter for. +
+
+
+

Config files

+
+ If you prefer normal shell commands for managing configuration, Caddy's CLI wraps the API endpoints for you. +
+
+
+ +
+
+ + + + +
+
+

+ Automatic HTTPS +

+

+ Our flagship feature, powered by CertMagic. Caddy is the first and only major server that enables HTTPS by default, and automatically procures and renews certificates for all your sites. +

+

+ Fully-native, integrated auto-HTTPS is far superior to any solution that requires external tooling or cron jobs. Caddy's certificate maintenance is the best in the industry because it is more robust, reliable, and scalable than any other solution. Caddy simplifies your infrastructure instead of complexifying it. +

+

+ Sure, you can try deploying 100,000 sites with Certbot and a cron job—but if that doesn't fall over by itself, the web server will. Only Caddy is designed to massively scale TLS certificates both horizontally and vertically. +

+

+ Never manually generate a CSR again. Never click a link in an email to download a certificate. Never (mis)configure your web server to use them. Never miss reminders to renew your certificates, one-by-one, every few months before they expire. You won't even have to think about certificates or TLS. +

+

+ It's truly automagic. +

+ +
+
+

Compliance

+
+ Caddy's TLS defaults are secure without any additional configuration, and passes compliance tests across various industries. +
+
    +
  • PCI DSS compliant
    • +
  • NIST compliant
    • +
  • HIPAA compliant
    • +
  • Industry best practices
    • +
+
+
+

On-Demand TLS

+
+ Serving domains that aren't yours? Or have lots of them? No problem! With just a few lines of config, On-Demand TLS gets certificates dynamically during TLS handshakes, scaling your deployments to tens of thousands of certs. This functionality is exclusive to Caddy. +
+
+
+

Certificate issuers

+
+ Get certificates from any issuing authority in a way compatible with them. Certificate issuers take a CSR and return a certificate resource. Most sites will simply use ACME to get certificates. But Caddy can also issue its own self-signed certificates for internal use, testing, or development. Caddy's issuer sources are pluggable, so Caddy can automate certificates from any issuer modules. +
+
    +
  • ACME
    • +
  • Internal (self-signed)
    • +
  • Microsoft Active Directory Certificate Services
    • +
+
+
+

Certificate managers

+
+ Unlike issuers, which take a CSR and return a certificate that Caddy has to manage, certificate managers are modules that can return always-valid certificates on-demand; that is, they are managing the certificates for us. Caddy can get interface with HTTP endpoints or Tailscale to get certificates in this manner, with other ways available through plugins. +
+
    +
  • HTTP
    • +
  • Tailscale
    • +
+
+
+

Cluster coordination

+
+ Across all Caddy instances configured with the same storage, Caddy automatically coordinates and shares resources across the cluster. This includes certificate operations and the certificates themselves, OCSP staples, and session ticket keys. This results in reduced latency for your clients and higher scalability. +
+
    +
  • Obtaining & renewing certificates
    • +
  • Loading existing certificates
    • +
  • OCSP staples
    • +
  • Session ticket keys (STEKs)
    • +
+
+
+

Redirect HTTP to HTTPS

+
+ By default, HTTP requests will be redirected to HTTPS. +
+
+ Automatic redirects +
+
+
+

OCSP

+
+ OCSP indicates when certificates are revoked. Servers should staple OCSP responses to certificates to provide clients with better security and privacy. Caddy is the first and only server to do this automatically and by default. It also caches responses to weather OCSP responder outages, and shares them across its cluster. This can all be disabled if needed. +
+
+ Automatic OCSP stapling with caching +
+
+
+

Must-Staple

+
+ Caddy can obtain certificates that force OCSP stapling if the CA supports it. This may grant a higher degree of security in the case of revocation. +
+
+
+

Revocation handling

+
+ Revoked certificates automatically get replaced. Because Caddy staples and refreshes OCSP responses, it can detect if your certificate has been revoked, and if so, it will replace i +
+
+
+

Session ticket hardening

+
+ TLS connections are pointless if an attacker steals the key to encrypt session tickets. Caddy has been academically cited as the only server to rotate these keys regularly to limit attack windows. +
+
+ Automatic STEK rotation +
+
+
+

Key types

+
+ You can customize the type of key used for your certificates. +
+
    +
  • Ed25519
    • +
  • ECDSA P256
    • +
  • ECDSA P384
    • +
  • RSA 2048
    • +
  • RSA 4096
    • +
+
+
+

Certificate lifetimes

+
+

Most ACME clients assume 90-day certificates, or don't expect certificates shorter than 7 days. Caddy can successfully manage certificates with lifetimes on the order of hours and minutes.

+

Instead of hard-coding a certain age before renewing, Caddy computes the age relative to the lifespan of each certificate, called a Renewal Window Ratio. By default, Caddy renews certificates after 2/3 of their usable lifetime. This ratio works for most validity periods, but can be adjusted.

+
+
+ Any lifetime +
+
+
+

Intelligent error handling

+
+ If Caddy can't get a certificate, errors are logged and Caddy will backoff exponentially and retry as long as needed until it succeeds (typically up to 30 days but could be longer). Caddy makes every reasonable effort to keep your certificate renewed. +
+
+ Exponential backoff +
+
+
+

Built-in throttling

+
+ Caddy conforms to best practices and doesn't blast CAs with requests for certificates; instead, each order is carefully timed to avoid overwhelming CA servers. +
+
+
+ +

ACME

+ +

+ Caddy's ACME client is best-in-class, with higher reliability and more production experience than any other integrated ACME client available today. Caddy has been using ACME since before the public availability of Let's Encrypt, and Caddy works with any ACME-compatible CA. +

+ +
+
+

Compatibility

+
+ Some ACME clients are only tested with Let's Encrypt. Caddy is guaranteed compatible with all ACME-capable CAs. +
+
+ All RFC 8555-compliant certificate authorities, such as: +
    +
  • Let's Encrypt
    • +
  • ZeroSSL
    • +
  • Google Trust Services
    • +
  • BuyPass
    • +
  • DigiCert
    • +
  • GlobalSign
    • +
  • SSL.com
    • +
  • Smallstep
    • +
+
+
+
+

Test endpoints

+
+ By default, Caddy will fall back to a CA's test or staging endpoint (if there is one) after a failed attempt at getting a certificate to avoid hitting CA-enforced production rate limits. This could also be an ACME server you set up solely for the purpose of validating DNS configurations. +
+
+ Let's Encrypt (others configurable) +
+
+
+

External account binding

+
+ Optionally configure External Account Binding (EAB) to enable Caddy to work with CAs that require you to have a separate account with them. +
+
+
+

Challenge types

+
+ Caddy supports all major ACME challenge types for Web PKI and can also be extended to support others. +
+
    +
  • HTTP-01
    • +
  • TLS-ALPN-01
    • +
  • DNS-01
    • +
+
+
+

Alternate challenge ports

+
+ While certain ACME challenges must use the standardized ports 80 and 443, Caddy supports listening for these on alternate ports if you are forwarding them through a router. +
+
    +
  • HTTP (default 80)
    • +
  • TLS-ALPN (default 443)
    • +
+
+
+

Smart challenge selection

+
+ Caddy learns what challenge types are most likely to succeed and tries those first. For example, if port 80 is blocked, it will learn to prefer the TLS-ALPN challenge which does not use port 80. +
+
+
+

DNS challenge integrations

+
+ The DNS challenge is the only one that does not require the CA being able to access your server. Solve the DNS challenge with integrations for dozens of DNS providers via libdns. This list is incomplete; see the full list of DNS providers. +
+
    +
  • ACME-DNS
    • +
  • AliDNS
    • +
  • Cloudflare
    • +
  • DigitalOcean
    • +
  • DNSPod
    • +
  • DuckDNS
    • +
  • DynDNS
    • +
  • EasyDNS
    • +
  • Gandi
    • +
  • GoDaddy
    • +
  • Google Cloud DNS
    • +
  • Hetzner
    • +
  • Linode
    • +
  • Name.com
    • +
  • Namecheap
    • +
  • Namesilo
    • +
  • Netlify
    • +
  • OVH
    • +
  • Porkbun
    • +
  • PowerDNS
    • +
  • RFC 2136
    • +
  • Route 53
    • +
  • Scaleway
    • +
  • Vercel
    • +
  • Vultr
    • +
  • See all...
    • +
+
+
+

Trusted CA certificates

+
+ Optionally configure root certificates you trust when interacting with your CA of choice; this is helpful for internal PKI where trust is established without public CAs. +
+
+
+

Preferred chains

+
+ When the CA offers multiple certificate chains, Caddy gives you the ability to customize which one to download and use. +
+
    +
  • Smallest
    • +
  • CommonName of root
    • +
  • CommonName of any
    • +
+
+
+ +
+
+ + + + + +
+
+

+ HTTP server +

+

+ Caddy's HTTP server is one-of-a-kind: powerful, extensible, efficient, and modern. +

+
+
+

HTTP versions

+
+ Caddy's HTTP server supports all major versions of HTTP and enables them by default (except H2C which is insecure, but available). You can customize exactly which versions you want to serve. +
+
    +
  • HTTP/1.1
    • +
  • HTTP/2
    • +
  • HTTP/2 over cleartext (H2C)
    • +
  • HTTP/3
    • +
+
+
+

HTTPS

+
+ Caddy's flagship feature is enabling HTTPS automatically and by default. You can control how it works or disable aspects: HTTP redirects, certificate management, certain hostnames, etc. +
+
+ Automatic +
+
+
+

Listen interfaces

+
+ Each HTTP server can bind to one or more sockets and network interfaces. For ports, you can specify specific host interface or all interfaces with just a port. All varieties of unix sockets are also supported. +
+
    +
  • TCP
    • +
  • UDP
    • +
  • Unix sockets
    • +
+
+
+

Listener wrappers

+
+ Listeners can be wrapped by modules that operate at the connection-accept level. +
+
    +
  • Redirect HTTP on HTTPS port
    • +
  • PROXY protocol
    • +
  • Tailscale
    • +
+
+
+

Timeouts

+
+ Setting timeouts is an important defensive measure for production environments, but must be tuned carefully to accommodate legitimate slow clients with large downloads or uploads. +
+
    +
  • Read timeout
    • +
  • Read HTTP header timeout
    • +
  • Write timeout
    • +
  • Idle timeout
    • +
  • TCP keepalive interval
    • +
+
+
+

Full duplex communication

+
+ Concurrent reading and writing of HTTP/1 is not supported by all clients, but can be enabled for certain clients and applications that require it. +
+
    +
  • Configurable for HTTP/1
    • +
  • Default for HTTP/2
    • +
+
+
+

Error handling

+
+ Caddy gives you full control over handling errors to give you clients the best/desired experience. +
+
+ Custom error routes +
+
+
+

TLS termination

+
+ Terminate TLS (formerly "SSL") with sensible defaults that you can customize to give you fine-grained control over TLS handshakes. You can assign policies to clients based on various factors such as ServerName (SNI) or remote IP. +
+
    +
  • TLS 1.2
    • +
  • TLS 1.3
    • +
  • Client authentication (TLS mutual auth; mTLS)
    • +
  • Client auth modes: request, require, verify if given, require and verify
    • +
  • Cipher suites
    • +
  • Curves
    • +
  • ALPN
    • +
  • Limit protocol versions
    • +
  • Default SNI
    • +
  • Fallback SNI
    • +
+
+
+

Cross-site security

+
+ Caddy often serves multiple sites on the same socket, so Caddy automatically enables protections to keep your sites safe if any of them have TLS client auth enabled. +
+
+ Verification that TLS ServerName and HTTP Host header match +
+
+
+

Access logs

+
+ Enable zero-allocation, structured access logs for the ultimate understanding of client requests and responses. Customize using Caddy's built-in logging configuration or the use of third-party modules. +
+
    +
  • More useful than Common Log Format (CLF)
    • +
  • Request headers (except sensitive fields)
    • +
  • Response headers
    • +
  • Remote IP
    • +
  • Latency
    • +
+
+
+

Observability

+
+ Your web server can be monitored using standards-compatible metrics. +
+
+ Prometheus metrics, open telemetry +
+
+
+

Request handling

+
+ The HTTP server handles requests using custom routes consisting of specific handlers in the order you define. A separate error route can be defined for custom error handling. You have a high degree of flexibility with HTTP handling. See below for available HTTP handler modules. +
+
+ Composable routes (and separate error handling routes) +
+
+
+

Request filters

+
+ Apply handlers to only certain requests using matchers, which classify requests based on various properties. Matchers are also used for filtering. They are extensible and pluggable, so there's no limit to how specific and custom your routes can be! Some matchers support regular expressions. All are quite fast. And matchers can be combined in sets so they can be joined with AND, OR, and NOT logic. +
+
    +
  • Host
    • +
  • Path
    • +
  • Method
    • +
  • Headers
    • +
  • Protocol
    • +
  • Remote IP
    • +
  • Arbitrary CEL expression
    • +
  • File (existence, size, modify date)
    • +
  • HTTP route variable
    • +
  • Logical NOT
    • +
  • Geolocation
    • +
  • Remote host
    • +
+
+
+ +

HTTP handlers

+ +

+ Handlers are modules that can be composed together to handle incoming requests precisely the way you want. Handler modules are, like the rest of Caddy, extensible and pluggable. It is not really feasible for us to list all the handlers here. +

+

+ In practice, handlers are paired with matchers which filter or classify requests based on various properties such as their path, headers, query string, method, and more. This allows you to selectively apply any and all of these handlers to certain requests. +

+ +
+
+

ACME server

+
+ Right out of the box, Caddy ships with a production-ready ACME server, perfect for your internal PKI. Automate mTLS certificates inside your infrastructure with ease. Powered by Smallstep libraries. +
+
+
+

Authelia

+
+ Secure routes with authentication using Authelia. +
+
+
+

Authentication

+
+ Authenticate users with an extensible authentication module. Extended by auth providers, this handler returns an error if the user cannot be authenticated by any configured providers. HTTP basicauth is included standard, and unlike other servers, passwords are hashed when setting up basicauth (since it's essentially a password database), enhancing security. +
+
    +
  • HTTP Basic authentication
    • +
  • JWT
    • +
  • Discord
    • +
  • Forms
    • +
  • SAML
    • +
+
+
+

Advanced auth

+
+ With a full suite of authentication and authorization features, the caddy-security module provides a variety of robust auth solutions. +
+
    +
  • Form-based
    • +
  • Local
    • +
  • Basic
    • +
  • LDAP
    • +
  • OpenID Connect
    • +
  • OAuth 2
    • +
  • SAML
    • +
+
+
+

Cache

+
+ Easily enable caching to serve more clients and increase performance. This cache module is compliant with RFC 7234 and supports tag-based cache purge, distributed and local storage, key generation tweaking, and more. Multiple backends are supported! +
+
    +
  • Badger
    • +
  • Etcd
    • +
  • NutsDB
    • +
  • Olric
    • +
  • Redis
    • +
+
+
+

Encode

+
+ Compress, encode, or otherwise transform HTTP responses on-the-fly with pluggable encoding modules. Compressing responses is as easy as a single line of configuration, and encodings won't be applied to responses that are already in a compressed format or are too small to be worthwhile. +
+
    +
  • Gzip
    • +
  • Zstandard (zstd)
    • +
  • Brotli
    • +
+
+
+

File server

+
+ A powerful, flexible, and efficient static file server that is described in detail below. +
+
+
+

Go package vanity paths

+
+ A simple handler that implements vanity import paths for Go packages. +
+
+
+

gRPC-Web bridging

+
+ Bridge/convert gRPC-Web requests to gRPC for your backend app. +
+
+
+

Header manipulation

+
+ Modify HTTP request and response headers. Adding, setting, deleting, and replacing substrings in header fields is fast, but regular expressions are also supported for advanced use. Response header manipulations can be deferred until the very end when the response starts to be written, and can even be made conditional on response status code or header values. +
+
    +
  • Add
    • +
  • Set (overwrite)
    • +
  • Delete
    • +
  • Substring replace
    • +
+
+
+

Image filtering

+
+ Perform adjustments on images on-the-fly. +
+
    +
  • Crop
    • +
  • Fit
    • +
  • Flip
    • +
  • Resize
    • +
  • Rotate
    • +
  • Sharpen
    • +
+
+
+

Map

+
+ Assign variable/placeholder values based on input values; similar to a lookup table. +
+
+
+

Mercure

+
+ Make your Caddy instance a Mercure hub: an open, easy, fast, reliable and battery-efficient solution for real-time communications. +
+
+
+

Metrics

+
+ Expose a /metrics endpoint for use with Prometheus-compatible systems and other monitoring tools. +
+
+
+

HTTP/2 server push

+
+ Proactively push resources to clients before they request it when HTTP/2 is used. (May be deprecated by browsers, but Caddy still has a valid implementation that is useful in certain applications.) +
+
+
+

Rate limiting

+
+ Advanced, enterprise-grade rate limiter implemented using a ring buffer and sliding window algorithm that scales massively based on zone keys. Configure a cluster of Caddy instances with the same storage to distribute rate limiting across your fleet. No memory bound required like with other enterprise servers. +
+
    +
  • Local or distributed
    • +
  • Multiple zones
    • +
  • Buffer pooling
    • +
  • Only 1 goroutine
    • +
  • Configurable O(Kn) memory management
    • +
  • State persisted through reloads
    • +
  • Sets Retry-After header
    • +
  • Optional jitter
    • +
  • Highly programmable
    • +
+
+
+

Request body controls

+
+ Restrict the size of the request body by rejecting requests that are too large. +
+
+
+

Reverse proxy

+
+ Caddy has a world-class reverse proxy, described in detail in a section below. +
+
+
+

Rewrite requests

+
+ Make internal changes to requests before continuing to process them. This is useful to accept requests that need to be changed to conform to an expectation later on. Various aspects of the request can be changed such as method and URI. +
+
    +
  • Method
    • +
  • URI (path, query string)
    • +
  • Strip path prefix or suffix
    • +
  • Regular expression support
    • +
  • Intelligent URL-encoding and forward-slash handling
    • +
+
+
+

Static responses

+
+ Hard-code a static response into your config, with the ability to set the status code, header fields, and body. (This is often used to respond with HTTP redirects.) The connection may then be gracefully closed, or forcefully aborted if needed. +
+
+
+

Subrouting

+
+ Group handlers into a "subroute" to treat several handlers as one, making certain logic easier to reason about. +
+
+
+

Templates

+
+ Responses can be evaluated as templates, which give you the ability to turn proxied or static content into rich, dynamic content with variables, if statements, markdown rendering (with front matter support), and more. +
+
+
+

Tracing

+
+ Support for distributed tracing using OpenTelemetry. +
+
+
+

Variables

+
+ Read and write variables that can be used internally as you process requests. +
+
+
+

WebDAV

+
+ Become a WebDAV server with one or two lines of config. Compatible with most WebDAV clients. +
+
+
+
+
+ + + +
+
+

+ Reverse proxy +

+

+ Caddy has the most flexible general-purpose reverse proxy in the world, featuring advanced request and response handling, dynamic routing, health checking, load balancing, circuit breaking, and more. +

+

+ What makes Caddy's proxy unique is its design. Only the client-facing side of the proxy needs to be HTTP; the transport underlying the roundtrip with the backend can be fulfilled with any protocol! +

+

+ Moreover, our proxy can be programmed with highly dynamic upstreams. That is, the available upstreams can change during in-flight requests! If no backends are available, Caddy can hold onto the request until one is. +

+ +

High-level proxy features

+ +
+
+

Transports

+
+ Transports are how Caddy gets the response from the backend. Caddy's proxy can be a front for protocols other than HTTP by using alternate transport modules. This allows Caddy to generate HTTP responses from backends that don't even speak HTTP! +
+
    +
  • HTTP
    • +
  • FastCGI
    • +
  • NTLM
    • +
+
+
+

Load balancing

+
+ Selecting upstreams is a crucial function of any modern reverse proxy. Caddy has a variety of built-in load balancing policies to choose from to suit any production services. Some policies are extremely fast and lightweight; others provide upstream affinity based on properties of the client or request; others strive for even distribution by counting connections or using randomness and weights. +
+
    +
  • Random
    • +
  • Random Choose-N
    • +
  • Least connections
    • +
  • Round robin
    • +
  • Weighted round robin
    • +
  • First available
    • +
  • Remote IP hash
    • +
  • Client IP hash
    • +
  • URI hash
    • +
  • Query hash
    • +
  • Header hash
    • +
  • Cookie hash
    • +
+
+
+

Circuit breaking

+
+ A circuit breaker module can temporarily mark a backend as down before it actually goes down, to keep it up. +
+
+ Latency-based +
+
+
+

Health checking

+
+ Health checks detect when upstreams are unavailable. Passive health checks infer status from actual requests. Active health checks work in the background, out-of-band of client requests. +
+
    +
  • Active
    • +
  • Passive
    • +
+
+
+

Observability

+
+ The admin API exposes an endpoint to retrieve the traffic count and health status of the proxy upstreams. +
+
+
+

Upstream sources

+
+ Caddy can get the list of upstreams in various ways. The most common is to write them into the configuration (static). Other ways are dynamic, by which a list of upstreams are returned for each request (these utilize configurable caching to enhance performance). +
+
    +
  • Static
    • +
  • Dynamic: A records
    • +
  • Dynamic: SRV records
    • +
  • Dynamic: Multiple sources combined
    • +
+
+
+

Retries

+
+ Requests can be retried until a backend is available to successfully handle the request. During this time, the list of upstreams may even be updated while the request is still pending! +
+
+
+

Streaming

+
+ Responses can be streamed directly to the client, or for better wire performance, buffered slightly and flushed periodically. +
+
+
+

Trusted proxies

+
+ In order to use proxy-related headers like X-Forwarded-For, you can specify a list of IP ranges of proxies you trust. By default Caddy doesn't trust the clients. +
+
+
+

Header manipulation

+
+ Headers can be modified in the request going up to the backend and the response coming back down from the backend. This is similar to the general HTTP server's header handler, but this is applied while proxying. +
+
    +
  • Add
    • +
  • Set (overwrite)
    • +
  • Delete
    • +
  • Substring replace
    • +
+
+
+

Buffering

+
+ The proxy can optionally read the entire body before flushing it. This uses more memory but can be required by some backend applications or clients in some cases. +
+
    +
  • Requests
    • +
  • Responses
    • +
+
+
+

Request rewriting

+
+ Rewriting is a different concern from proxying and is normally handled separately, but sometimes you need to rewrite requests using information from the proxy like the chosen upstream. Caddy's proxy lets you do this. +
+
+
+

Response interception

+
+ By default, Caddy's proxy simply writes responses to the client. However, you can intercept the upstream's response and handle it in other ways. This includes matching only certain responses and invoking a custom handler chain you specify. +
+
+
+ +

Active health checks

+

+ Active health checks assume a backend is down by default until that is confirmed otherwise by a health check. +

+ +
+
+

HTTP request parameters

+
+ Active health checks are performed against an HTTP endpoint on the upstream. You can customize the parameters for these HTTP requests to work for you. +
+
    +
  • Path & query string
    • +
  • Port
    • +
  • Headers
    • +
+
+
+

Timing

+
+ You can customize the interval at which active health checks are performed. +
+
+
+

Success criteria

+
+ Each active health check can be customized with a set of criteria to determine healthy or unhealthy status. +
+
    +
  • Response timeout
    • +
  • HTTP status code
    • +
  • Regular expression match on body
    • +
+
+
+

Failure safety

+
+ Backends that are experiencing bugs and difficulties may sometimes respond with unexpectedly large response bodies. Caddy lets you limit this to preserve proxy resources. +
+
+ Limit response size +
+
+
+ +

Passive health checks

+

+ Passive health checks assume a backend is up by default until failure criteria are met in the course of proxying requests. +

+ +
+
+

Failure criteria

+
+ All passive health checks count connection failures. In addition, you can set more criteria needed to deem a backend as healthy during a request. +
+
    +
  • Concurrent request limit exceeded
    • +
  • HTTP Status
    • +
  • Latency
    • +
+
+
+

Failure memory

+
+ You can customize how long to remember failures and how many failures need to be in memory to consider a backend to be down. +
+
+
+ + +

HTTP transport

+

+ This is the default transport module. It crafts a proxied HTTP request to obtain an HTTP response from the backend. +

+ +
+
+

DNS resolvers

+
+ The system resolvers are used by default, but you can specify custom DNS resolvers per proxy handler. +
+
+
+

TLS

+
+ Caddy can be configured to support TLS (formerly known as SSL) to the upstream. +
+
    +
  • Custom root CA pool
    • +
  • Client authentication to backend
    • +
  • Custom handshake timeout
    • +
  • Server Name Indicator (SNI)
    • +
  • Renegotiation level
    • +
  • Exempt certain ports from TLS
    • +
+
+
+

Connection pooling

+
+ Connections to backends are pooled for maximum efficiency and minimal latency. +
+
    +
  • HTTP Keep-Alive
    • +
  • Custom probe interval
    • +
  • Maximum idle connections (total and per-host)
    • +
  • Idle connection timeout
    • +
+
+
+

Compression

+
+ Caddy can compress requests for the roundtrip with the backend. +
+
+ Gzip +
+
+
+

Connection limit

+
+ You can limit the number of connections per host. +
+
+
+

PROXY Protocol

+
+ The PROXY Protocol v1 and v2 are both supported when connecting to upstreams. +
+
+
+

Timeouts

+
+ Various timeouts can be configured; some have sensible default values. +
+
    +
  • Connection (dial)
    • +
  • RFC 6555 fallback
    • +
  • Reading response headers
    • +
  • Expect continue
    • +
  • Read
    • +
  • Write
    • +
+
+
+

Custom buffer sizes

+
+ Tune the size of read/write buffers if you find that your application performs better with certain settings. +
+
    +
  • Read buffers
    • +
  • Write buffers
    • +
+
+
+

HTTP versions

+
+ Caddy's proxy supports multiple HTTP versions with the backend. By default, HTTP/1.1 and HTTP/2 are supported. +
+
    +
  • HTTP/1.1
    • +
  • HTTP/2
    • +
  • H2C (HTTP/2 over cleartext)
    • +
+
+
+ +

FastCGI transport

+

+ FastCGI is typically used to serve PHP applications via php-fpm. FastCGI responders may require additional information about the script being run such as script name, path relative to root, etc., and Caddy's FastCGI transport takes care of all of that and makes it configurable. +

+ +
+
+

Highly efficient

+
+ Caddy's FastCGI client implementation has been optimized to rival the performance of memory-unsafe clients written in C, sometimes even surpassing their performance. +
+
+
+

Path splitting

+
+ The path can be split, usually at the extension, to compute the proper PATH_INFO variable. +
+
+
+

Resolve root symlink

+
+ Optionally require paths declared to symlinks to be updated if the symlink changes without php-fpm being restarted. +
+
+
+

Environment variables

+
+ Read from the parent environment, and also set custom environment variables for your CGI script. +
+
+
+

Timeouts

+
+ Set timeouts to conserve resources. +
+
    +
  • Dial (connect)
    • +
  • Read
    • +
  • Write
    • +
+
+
+

Capture stderr

+
+ Caddy can capture the output to stderr from the upstream and log them for visibility. +
+
+
+ +
+
+ + +
+
+

+ Static file server +

+

+ Caddy's file server is the premier way of serving static files for your website. +

+

+ It's simple: specify a root directory from which to serve the files, then each request path is automatically appended to the root to get the full path of the file to serve. +

+
+
+

Kernel acceleration

+
+ Caddy bypasses user-space buffers whenever possible to speed up file downloads by a significant factor. +
+
+ sendfile +
+
+
+

Virtual file systems

+
+ By default, Caddy serves files from a directory you specify on the local disk, but this file access is pluggable and can be replaced by any virtualized file system modules. This allows you to serve static files from any file store such as databases, cloud storage, or even assets embedded directly in the web server binary! +
+
    +
  • Local disk
    • +
  • Embedded assets
    • +
  • Amazon AWS S3
    • +
+
+
+

Precompressed files

+
+ If your deployment pipeline compresses site resources, Caddy can automatically detect them and serve them in their "precompressed" encoding for higher efficiency and greater throughput. +
+
    +
  • Gzip
    • +
  • Brotli
    • +
  • Zstandard
    • +
+
+
+

Hide files and folders

+
+ Increase your security posture by proactively hiding potentially-sensitive files and folders that do or could exist in your site root. You can specify individual file/folder paths, filenames regardless of their path, or glob matches to hide files/folders with a particular pattern. +
+
+ Exact paths, filenames, globular matching +
+
+
+

Index filenames

+
+ Index files are files that are served if a directory is requested by the client. The filenames of index files to look for are customizable. Directory browsing can optionally be enabled if an index file is not found in a requested directory. +
+
+ index.html, index.txt (customizable) +
+
+
+

Conditional requests

+
+ Etag, Last-Modified, and related headers are supported. +
+
    +
  • Etag
    • +
  • Last-Modified
    • +
  • If-Match
    • +
  • If-None-Match
    • +
  • If-Modified-Since
    • +
  • If-Unmodified-Since
    • +
  • If-Range
    • +
+
+
+

Range requests

+
+ Common for streaming large files and resuming downloads, clients requesting certain ranges of files will not be disappointed or surprised. Caddy properly handles HTTP requests with Range headers. +
+
+
+

Canonical paths

+
+ In general, there are multiple URIs for a single file or directory. For example: /, /index.html, and /index.html/ represent the same resource. Caddy uses HTTP redirects to enforce path canonicalization (removing trailing slashes from files, and adding them for directories). +
+
+
+

Pass-thru mode

+
+ Sometimes you only want to serve a file if it exists, otherwise continue with the next handler in the chain, rather than returning an error to the client. +
+
+
+ + + +
+
+

File browser

+

+ Caddy's file server comes alive through its modern file browser that looks attractive on mobile and desktop. It has more features and utility than any other standard HTTP file server! +

+
+ + + + +
+ +
+
+

Folder listings

+
+ Show the list of files in a folder when no index file (below) exists in that folder. +
+
+ Exact paths, filenames, globular matching +
+
+
+

Day and night themes

+
+ The color scheme automatically adjusts to match the system theme, whether it be light or dark, to avoid blinding you or being hard to read. + + + + +
+
    +
  • Light mode
    • +
  • Dark mode
    • +
+
+
+

Sort by columns

+
+ Quickly distill information about each directory and find items faster with sticky column sorting. +
+
    +
  • File/directory
    • +
  • Name
    • +
  • Size
    • +
  • Date modified
    • +
+
+
+

Filter

+
+ Every page load automatically focuses the cursor on a search box, so you can start typing a filename and filter large listings instantly. + + + + +
+
+
+

Layout

+
+ Files can be shown in different layouts depending on how you want to view the listing. For example, the grid view is great for galleries. + + + + +
+
    +
  • List
    • +
  • Grid
    • +
+
+
+

Responsive design

+
+ The page width fluidly adjusts to accommodate screens of all sizes. Links are sufficiently sized to be easily tappable on touchscreens while still being information-dense enough to be useful. +
+
+
+

JSON API

+
+ Requests with an Accept-Encoding: application/json header will be replied to with a JSON payload for programmatic or scripted access to your file listing. +
+
+
+

Customizable listing template

+
+ If the default template isn't a good fit or you want to spice things up, customize the browse template to look and act any way you want! +
+
+
+

File size visualization

+
+ File sizes are indicated by the length of the bar behind them, making it quick and easy to find outlier large and small files or to compare relative sizes at a glance. + + + + +
+
+
+

File type icons

+
+ The file server recognizes dozens of common file types and shows associated icons to make identification easier when scanning the page. + + + + +
+
+
+
+
+ +
+
+
+ {{$n := randInt 0 5}} + {{if eq $n 1}} + + + + {{else if eq $n 2}} + + + + {{else if eq $n 3}} + + {{else if eq $n 4}} + + {{else}} + + {{end}} +
+

+ Caddy is a living project with a TON of features. This page is not yet a comprehensive list of all the features and benefits provided by Caddy because there's so many to mention. We welcome contributions on GitHub! +

+
+ + +
+ + + + +
+ + + {{include "/includes/footer.html"}} + + diff --git a/src/includes/account/head.html b/src/includes/account/head.html deleted file mode 100644 index 2ff15c3..0000000 --- a/src/includes/account/head.html +++ /dev/null @@ -1,8 +0,0 @@ -{{define "account-head"}} - {{import "/includes/head.html"}} - {{template "head"}} - - - - -{{end}} diff --git a/src/includes/docs/head.html b/src/includes/docs/head.html deleted file mode 100644 index be64df1..0000000 --- a/src/includes/docs/head.html +++ /dev/null @@ -1,13 +0,0 @@ -{{define "docs-head"}} - {{import "/includes/head.html"}} - {{template "head"}} - - - {{$directives := list }} - {{range $i, $file := (listFiles "/docs/markdown/caddyfile/directives")}} - {{$directives = append $directives ($file | trimSuffix ".md")}} - {{end}} - - - -{{end}} diff --git a/src/includes/docs/header.html b/src/includes/docs/header.html deleted file mode 100644 index 56ae07c..0000000 --- a/src/includes/docs/header.html +++ /dev/null @@ -1,12 +0,0 @@ -
-
-
- -
Documentation
-
-
- a project -
-
- {{include "/includes/header-nav.html"}} -
\ No newline at end of file diff --git a/src/includes/examples/custom-ca.md b/src/includes/examples/custom-ca.md new file mode 100644 index 0000000..cae940a --- /dev/null +++ b/src/includes/examples/custom-ca.md @@ -0,0 +1,24 @@ +
+ +```caddy +{ + pki { + ca corporate { + name "Our Corporation Authority" + } + } +} + +internal.example.com { + # ACME endpoint: /acme/corporate/directory + acme_server { + ca corporate + } +} +``` + +
+ + \ No newline at end of file diff --git a/src/includes/examples/file-server.md b/src/includes/examples/file-server.md new file mode 100644 index 0000000..72f2641 --- /dev/null +++ b/src/includes/examples/file-server.md @@ -0,0 +1,63 @@ + + +
+ +```caddy +example.com + +root * /var/www + +# Serve precompressed files if present +file_server /downloads/* { + precompressed gzip zstd br +} + +# Compress everything else that would benefit +encode zstd gzip + +# Static site using database as file system +file_server /database/* { + fs sqlite data.sql +} + +# Static site embedded within the Caddy binary +file_server /embedded/* { + fs embedded +} + +# (Range/Etag/etc. all work without extra config) + +# Serve static site with directory listings +file_server browse +``` + +
diff --git a/src/includes/examples/json-automate-certs.md b/src/includes/examples/json-automate-certs.md new file mode 100644 index 0000000..4a1fd2b --- /dev/null +++ b/src/includes/examples/json-automate-certs.md @@ -0,0 +1,22 @@ +
+ +```json +{ + "apps": { + "tls": { + "certificates": { + "automate": [ + "example.com", + "sub.example.com", + "example.net" + ] + } + } + } +} +``` + +
+ diff --git a/src/includes/examples/local-https.md b/src/includes/examples/local-https.md new file mode 100644 index 0000000..2c1b058 --- /dev/null +++ b/src/includes/examples/local-https.md @@ -0,0 +1,21 @@ +
+ +```caddy +localhost { + respond "Hello from HTTPS!" +} + +192.168.1.10 { + respond "Also HTTPS!" +} + +http://localhost { + respond "Plain HTTP" +} +``` + +
+ + \ No newline at end of file diff --git a/src/includes/examples/on-demand.md b/src/includes/examples/on-demand.md new file mode 100644 index 0000000..aa3553a --- /dev/null +++ b/src/includes/examples/on-demand.md @@ -0,0 +1,36 @@ + + +
+ +```caddy +{ + on_demand_tls { + ask http://localhost:9123/check + } +} + +https:// { + tls { + on_demand + } + # reverse_proxy, etc... +} + +# other sites... +``` + +
diff --git a/src/includes/examples/proxy.md b/src/includes/examples/proxy.md new file mode 100644 index 0000000..97291f8 --- /dev/null +++ b/src/includes/examples/proxy.md @@ -0,0 +1,53 @@ + + +
+ +```caddy +example.com + +# Serve PHP sites +handle /blog/* { + root * /var/www/wordpress + php_fastcgi localhost:9000 + file_server +} + +# Proxy an autoscaling API with dynamic backends +reverse_proxy /api/* { + dynamic srv _api._tcp.example.com +} + +# Proxy a compute-heavy distributed service +# with load balancing and health checks +reverse_proxy /service/* { + to 10.0.1.1:80 10.0.1.2:80 10.0.1.3:80 + lb_policy least_conn + lb_try_duration 10s + fail_duration 5s +} + +# Proxy everything else to an HTTPS upstream +reverse_proxy https://service.example.com { + header_up Host {upstream_hostport} +} +``` + +
diff --git a/src/includes/examples/website-caddyfile.md b/src/includes/examples/website-caddyfile.md new file mode 100644 index 0000000..6a95dc8 --- /dev/null +++ b/src/includes/examples/website-caddyfile.md @@ -0,0 +1,23 @@ +
+ +```caddy +caddyserver.com + +root * src + +file_server +templates # markdown & syntax highlighting! +encode zstd gzip + +redir /docs/json /docs/json/ +rewrite /docs/json/* /docs/json/index.html +rewrite /docs/* /docs/index.html + +reverse_proxy /api/* localhost:9002 +``` + +
+ + \ No newline at end of file diff --git a/src/includes/footer.html b/src/includes/footer.html index e3f83c1..326609c 100644 --- a/src/includes/footer.html +++ b/src/includes/footer.html @@ -1,24 +1,49 @@ -
-
+
+

Caddy supports an open Web that promotes privacy, preserves data ownership, fosters innovation, freely allows varieties of client software, and safeguards human sanctity.

+
+ + + +
+ + +
+
{{ maybe "hitCounter" .OriginalReq.URL.Path }}
+
+
+ \ No newline at end of file diff --git a/src/includes/head.html b/src/includes/head.html index c9269a0..e41449b 100644 --- a/src/includes/head.html +++ b/src/includes/head.html @@ -9,33 +9,36 @@ - - - + + + + + + + + - + - + - + - - + + + - - - - - + + @@ -45,8 +48,4 @@ gtag('js', new Date()); gtag('config', 'G-2DLB04LK4P'); - - - - {{end}} diff --git a/src/includes/header.html b/src/includes/header.html new file mode 100644 index 0000000..983f3ea --- /dev/null +++ b/src/includes/header.html @@ -0,0 +1,208 @@ +
+
+
+ + A ZeroSSL Project + + + + + + + + + + + Store + + + + + + + GitHub + + + + + + + + Theme: System + +
+
+
+ + + + + + + + +
+ Download + Sponsor +
+
+
\ No newline at end of file diff --git a/src/includes/quick-assist/content.md b/src/includes/quick-assist/content.md new file mode 100644 index 0000000..c2cbfab --- /dev/null +++ b/src/includes/quick-assist/content.md @@ -0,0 +1,136 @@ + + +
+ +
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
+curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
+curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
+sudo apt update
+sudo apt install caddy
+ +
+
+ +
dnf install 'dnf-command(copr)'
+dnf copr enable @caddy/caddy
+dnf install caddy
+ +
+
+ +
pacman -Syu caddy
+ +
+
+ +
brew install caddy
+ +
+
+ +

Chocolatey:

choco install caddy
+

Scoop:

scoop install caddy
+ +
+
+ +- Package name: [`caddy`](https://search.nixos.org/packages?channel=unstable&show=caddy&query=caddy) +- NixOS module: [`services.caddy`](https://search.nixos.org/options?channel=unstable&show=services.caddy.enable&query=services.caddy) + +
+
+ +In Termux: 
pkg install caddy
+ +
+
+ +

Webi

+

Linux and macOS:

+
curl -sS https://webi.sh/caddy | sh
+

Windows:

+
curl.exe https://webi.ms/caddy | powershell
+

Ansible

+
ansible-galaxy install nvjacobo.caddy
+ +
+
+ +
docker pull caddy
+ +
+
+ +Make sure to have `git` and the latest version of [Go](https://go.dev) installed. + +
git clone "https://github.com/caddyserver/caddy.git"
+cd caddy/cmd/caddy/
+go build
+ +
+
+ + +[`xcaddy`](https://github.com/caddyserver/xcaddy) is a command line tool that helps you build Caddy with plugins. A basic build looks like: + +
xcaddy build
+ +To build with plugins, use `--with`: + +
xcaddy build \
+	--with github.com/caddyserver/nginx-adapter
+	--with github.com/caddyserver/ntlm-transport@v0.1.1
+ +
+
+ +1. Obtain a Caddy binary: + - [from releases on GitHub](https://github.com/caddyserver/caddy/releases) (expand "Assets") + - Refer to [Verifying Asset Signatures](/docs/signature-verification) for how to verify the asset signature + - [from our download page](/download) + - [by building from source](/docs/build) (either with `go` or `xcaddy`) +2. [Install Caddy as a system service.](/docs/running#manual-installation) This is strongly recommended, especially for production servers. + +Place the binary in one of your `$PATH` (or `%PATH%` on Windows) directories so you can run `caddy` without typing the full path of the executable file. (Run `echo $PATH` to see the list of directories that qualify.) + +You can upgrade static binaries by replacing them with newer versions and restarting Caddy. The [`caddy upgrade` command](/docs/command-line#caddy-upgrade) can make this easy. + +
+
+ +On-demand TLS is designed for situations when you either don't control the domain names, or you have too many certificates to load all at once when the server starts. For every other use case, standard TLS automation is likely better suited. + +
+
+ + +In order to prevent abuse, you must first configure an `ask` endpoint so Caddy can check whether it should get a certificate. Add this to your global options at the top: + +```caddy +{ + on_demand_tls { + ask http://localhost:5555/check + } +} +``` + +Change that endpoint to be something you've set up that will respond with HTTP 200 if the domain given in the `domain=` query parameter is allowed to have a certificate. + +Then create a site block that serves all sites/hosts on the TLS port: + +```caddy +https:// { + tls { + on_demand + } +} +``` + +This is the minimum config to enable Caddy to accept and service TLS connections for arbitrary hosts. This config doesn't invoke any handlers. Usually you'll also [`reverse_proxy`](/docs/caddyfile/directives/reverse_proxy) to your backend application. + +
diff --git a/src/includes/quick-assist/core.html b/src/includes/quick-assist/core.html new file mode 100644 index 0000000..2b960f9 --- /dev/null +++ b/src/includes/quick-assist/core.html @@ -0,0 +1,103 @@ +{{ include "/includes/quick-assist/structure.html" }} + + +
+
+ Quick Assist + +
+
+

+
+
+ + + Reset + +
+
+
+ + + +
+{{ markdown (include "/includes/quick-assist/content.md") }} +
diff --git a/src/includes/quick-assist/structure.html b/src/includes/quick-assist/structure.html new file mode 100644 index 0000000..060a815 --- /dev/null +++ b/src/includes/quick-assist/structure.html @@ -0,0 +1,275 @@ + diff --git a/src/index.html b/src/index.html index 98905ec..39caeb7 100644 --- a/src/index.html +++ b/src/index.html @@ -3,1018 +3,713 @@ Caddy - The Ultimate Server with Automatic HTTPS {{import "/includes/head.html"}} - {{template "head"}} + {{template "head" .}} + + + + + - - + +
-
-
-
- -
a project
-
- {{include "/includes/header-nav.html"}} -
- -

The Ultimate Server

-

- Caddy 2 is a powerful, enterprise-ready, open source web server with automatic HTTPS written in Go -

- -
- Download - -
- then learn how to get started -

- Caddy is licensed with the Apache 2.0 open source license. -
-
-
- -
-
-
-
-

Fewer moving parts

-

- Caddy simplifies your infrastructure. It takes care of TLS certificate renewals, OCSP stapling, static file serving, reverse proxying, Kubernetes ingress, and more. -

-

- Its modular architecture means you can do more with a single, static binary that compiles for any platform. -

-

- Caddy runs great in containers because it has no dependencies—not even libc. Run Caddy practically anywhere. -

-

Documentation

-
- Caddy does the work of your WAF, web server, ingress, reverse proxy, TLS terminator, logging, caching, and TLS certificate management. -
-
-
- -
-
-
-
-

Best-in-class security

-

- Caddy is the only web server to use HTTPS automatically and by default. -

-

- Caddy obtains and renews TLS certificates for your sites automatically. It even staples OCSP responses. Its novel certificate management features are the most mature and reliable in its class. -

-

- Written in Go, Caddy offers greater memory safety than servers written in C. A hardened TLS stack powered by the Go standard library serves a significant portion of all Internet traffic. -

- -

Download

-
- Caddy is the only server to use HTTPS automatically and by default -
-
-
- -
-
-
-
-

Backed by Ardan

-

- Ardan Labs is the trusted partner of the Caddy Web Server open source project, providing enterprise-grade support to our clients. -

-

- Together, we consult and train, as well as develop, install, and maintain Caddy and its plugins to ensure your infrastructure runs smoothly and efficiently. Contact us to get started! -

-

Let's talk

-
- Ardan Labs -
-
-
- -
-
-
-
-

File server and proxy

-

- Caddy is both a flexible, efficient static file server and a powerful, scalable reverse proxy. -

-

- Use it to serve your static site with compression, template evaluation, Markdown rendering, and more. -

-

- Or use it as a dynamic reverse proxy to any number of backends, complete with active and passive health checks, load balancing, circuit breaking, caching, and more. -

-

Download

-
- Caddy is the only server to use HTTPS automatically and by default -
-
-
- -
-
-

1-Liners

-

- These commands are production-ready. When given a domain name, Caddy will use HTTPS by default, which provisions and renews certificates for you.* -

-
* Requires domain's public A/AAAA DNS records pointed at your machine.
-
- -
-
Quick, local file server
-
-
$ caddy file-server
 - -
-
Public file server over HTTPS
-
-
$ caddy file-server --domain example.com
 - -
-
HTTPS reverse proxy
-
-
$ caddy reverse-proxy --from example.com --to localhost:9000
 - -
-
Run server with Caddyfile in working directory (if present)
-
-
$ caddy run
 - -
-
- Download - CLI Docs -
-
-
- - -
-
-

The Caddyfile

-

- A config file that's human-readable and easy to write by hand. Perfect for most common and manual configurations. -

-
- -
-
Local file server with template evaluation
-
-
localhost - -templates -file_server
 - -
-
HTTPS reverse proxy with custom load balancing and active health checks
-
-
example.com # Your site's domain name - -# Load balance between three backends with custom health checks -reverse_proxy 10.0.0.1:9000 10.0.0.2:9000 10.0.0.3:9000 { - lb_policy random_choose 2 - health_path /ok - health_interval 10s -}
 - -
-
HTTPS site with clean URLs, reverse proxying, compression, and templates
-
-
example.com - -# Templates give static sites some dynamic features -templates - -# Compress responses according to Accept-Encoding headers -encode gzip zstd - -# Make HTML file extension optional -try_files {path}.html {path} - -# Send API requests to backend -reverse_proxy /api/* localhost:9005 - -# Serve everything else from the file system -file_server
 - -
-
- Download - Caddyfile Docs -
-
-
- - -
-
-

Config API

-

- Caddy is dynamically configurable with a RESTful JSON API. Config updates are graceful, even on Windows. -

- Using JSON gives you absolute control over the edge of your compute platform, and is perfect for dynamic and automated deployments. -

-
- -
-
Set a new configuration
-
-
POST /config/ - -{ - "apps": { - "http": { - "servers": { - "example": { - "listen": ["127.0.0.1:2080"], - "routes": [{ - "@id": "demo", - "handle": [{ - "handler": "file_server", - "browse": {} - }] - }] - } - } - } - } -}
 - -
-
Export current configuration
-
-
GET /config/
 - -
-
Change only a specific part of the config
-
-
PUT /id/demo/handle/0 - -{"handler": "templates"}
 - -
-
-

- All changes made through the API are persisted to disk so they can continue to be used after restarts. -

- - Download - API Docs - Tutorial -
-
-
- - - - - - - - - - - - - -
- -
-
-
- -
Secure by Default
-

- Caddy is the only web server that uses HTTPS by default. A hardened TLS stack with modern protocols preserves privacy and exposes MITM attacks. -

-
-
- -
Config API
-

- As its primary mode of configuration, Caddy's REST API makes it easy to automate and integrate with your apps. -

-
-
- -
No Dependencies
-

- Because Caddy is written in Go, its binaries are entirely self-contained and run on every platform, including containers without libc. -

-
-
- -
Modular Stack
-

- Take back control over your compute edge. Caddy can be extended with everything you need using plugins. -

-
-
- -
-
✔ Static sites
-
✔ Dynamic sites
-
✔ Reverse proxy
-
-
-
✔ Dynamic config
-
✔ Extensible core
-
✔ Automagic TLS
-
- - Features -
- - -
-

General

-

- Caddy 2 was boldly engineered to simplify your infrastructure and give you control over the edge of your compute platform. -

- - -

Architecture

-
-
-
Extensible
-

- Caddy can embed any Go application as a plugin, and has first-class support for plugins of plugins. -

-
-
-
Minimal Global State
-

- Global state is common in servers, but tends to be error-prone and a bottleneck, so Caddy 2 uses a novel design that limits global state. -

-
-
-
Lightweight
-

- For all its features, Caddy runs lightly and efficiently with relatively low memory footprint and high throughput. -

-
-
-
Multi-core
-

- When the going gets tough, Caddy gets going on more CPUs. Go's scheduler understands Go code, and goroutines are more lightweight than system threads. -

-
-
-
Static Binary
-

- Caddy is a single executable file with no dependencies, not even libc. Literally just needs some metal and a kernel. Put Caddy in your PATH and run it. Done. -

-
-
-
Cross-Platform
-

- Caddy runs on Windows, macOS, Linux, BSD, Android, Solaris, 32-bit, amd64, ARM, aarch64, mips64... almost anything to which Go compiles. -

-
-
- - -

Configuration

-
-
-
JSON Structure
-

- Caddy's native config format is JSON, so it is familiar and highly interoperable with existing systems and tools. -

-
-
-
REST API
-

- Caddy's configuration is received through a REST endpoint as a single JSON document, making it highly programmable. -

-
-
-
Config Files Optional
-

- You can use config files with Caddy's CLI, which converts them to API requests for you under the hood. -

-
-
-
Config Adapters
-

- Bring your own config! Config adapters translate various config formats (Caddyfile, TOML, NGINX, etc.) into Caddy's native JSON. -

-
-
-
The Caddyfile
-

- An easy, intuitive way to configure your site. It's not scripting, and not hard to memorize. Rolls off the fingers. You'll really like it. -

-
-
-
Unified Config
-

- All configuration is contained within a single JSON document so there are fewer hidden factors affecting your config. -

-
-
-
Partial Updates
-

- When you have just small changes to make, Caddy's API lets you update just the relevant parts of its config. -

-
-
-
Fine-Grained Control
-

- Caddy's native JSON exposes the actual fields allocated in memory by the running server to give you more control. -

-
-
-
Export
-

- You can export a live copy of Caddy's current configuration with a GET request to its API. -

-
-
-
Efficient Reloads
-

- Config updates are finely tuned for efficiency so you can reload config dozens of times per second. -

-
-
-
Graceful Reloads
-

- Config changes take effect without downtime or closing sockets—even on Windows. -

-
-
-
Config Validation
-

- You can use Caddy's CLI to preview and validate configurations before applying them. -

-
-
- - - - - - -

Basic Features

-
-
-
The Caddyfile
-

- An easy, intuitive way to configure your site. It's not scripting, and not hard to memorize. Rolls off the fingers. You'll really like it. -

-
-
-
Static Files
-

- By default, Caddy will serve static files in the current working directory. It's so brilliantly simple and works fast. -

-
-
-
Dynamic Sites
-

- Caddy can also be used to serve dynamic sites with templates, proxying, FastCGI, and by the use of plugins. -

-
-
-
Command Line Interface
-

- Customize how Caddy runs with its simple, cross-platform command line interface; especially great for quick, one-off server instances. -

-
-
-
Plugins
-

- Caddy can be extended with plugins. All apps, Caddyfile directives, HTTP handlers, and other features are plugins! They're easy to write and get compiled in directly. -

-
-
-
Multi-core
-

- When the going gets tough, Caddy gets going on more CPUs. Go's scheduler understands Go code, and goroutines are more lightweight than system threads. So yeah, it's fast. -

-
-
-
Embeddable
-

- Writing another program or web service that could use a powerful web server or reverse proxy? Caddy can be used like a library in your Go program. -

-
-
-
Caddyfile Validation
-

- Caddy can parse and verify your Caddyfile without actually running it. -

-
-
-
Process Log
-

- Caddy can write a log of all its significant events, especially errors. Log to a file, stdout/stderr, or a local or remote system log! -

-
-
-
Log Rolling
-

- When log files get large, Caddy will automatically rotate them to conserve disk space. -

-
-
-
+ {{include "/includes/header.html" "dark-header"}} - - - - -
-

Security and Privacy

-

- Caddy's flagship features are security and privacy. Caddy is the first and only web server to enable HTTPS automatically and by default. -

- -

TLS

-
-
-
TLS 1.3
-

- TLS 1.3 is the newest standard for transport security, which is faster and more secure than its predecessors. -

-
-
-
Modern Cipher Suites
-

- Caddy uses the best crypto technologies including AES-GCM, ChaCha, and ECC by default, balancing security and compatibility. You can customize which ciphers are allowed. -

-
- -
-
Memory Safety
-

- Caddy is the only web server in its class that is impervious to bugs like Heartbleed and buffer overflows because it is written in the memory-safe language of Go. -

-
-
-
Client Authentication
-

- With TLS client auth, you can configure Caddy to allow only certain clients to connect to your service. -

-
-
-
Hardened Stack
-

- Caddy is proudly written in Go, and its TLS stack is powered by the robust crypto/tls package in the Go standard library, trusted by the world's largest content distributors. -

-
-
-
PCI Compliant
-

- Companies choose Caddy because its TLS configuration is PCI-compliant by default. It has even saved some companies hours before losing certification! -

-
-
-
Scalable Storage
-

- TLS assets are stored on disk, but the storage mechanism can be swapped out for custom implementations so you can deploy and coordinate a fleet of Caddy instances. -

-
-
-
Key Rotation
-

- Caddy is cited as the only web server to rotate TLS session ticket keys by default. This helps preserve forward secrecy, i.e. visitor privacy. -

-
-
-
Server Name Indication
-

- Caddy uses the TLS extension Server Name Indication (SNI) to be able to host multiple sites on a single interface. Like most features, this just works. -

-
-
-
Redirect HTTP to HTTPS
-

- Caddy's automatic HTTPS feature includes redirecting HTTP to HTTPS for you by default. -

-
-
- -

Certificates

-
-
-
Auto Obtain
-

- Caddy obtains certificates for you automatically using Let's Encrypt. Any ACME-compatible CA can be used. Caddy was the first web server to implement this technology. -

-
-
-
Auto Renew
-

- Never deal with certificates again! Certificates are automatically renewed in the background before they get close to expiring. -

-
-
-
Dynamic Cert Loading
-

- Caddy is the only web server that can obtain certificates during a TLS handshake and use it right away. -

-
-
-
Bring Your Own
-

- If you still prefer to manage certificates yourself, you can give Caddy your certificate and key files (PEM format) like you're used to. -

-
-
-
Bulk Cert Loading
-

- If you manage many certificates yourself, you can give Caddy an entire folder to load certificates from. -

-
-
-
Easy Self-Signed Certs
-

- For easy local development and testing, Caddy can generate and manage self-signed certificates for you without any hassle. -

-
-
-
SAN Certificates
-

- Caddy fully accepts SAN certificates for times when you may be managing your own SAN certificates and wish to use those instead. -

-
-
-
Cluster Support
-

- Caddy can share managed certificates stored on disk with other instances and synchronize renewals in fleet deployments. -

-
-
-
Scalable
-

- Caddy's certificate management scales well up to tens of thousands of sites and tens of thousands of certificates per instance. -

-
-
-
Wildcards
-

- When needed, Caddy can obtain and renew wildcard certificates for you when you have many related subdomains to serve. -

-
-
- -

OCSP

-
-
-
Stapling
-

- Caddy staples OCSP responses to every qualifying certificate by default. Caddy's OCSP stapling is more robust against network failure than other web servers. -

-
-
-
Caching
-

- Every OCSP response is cached on disk to preserve integrity through restarts, in case the responder goes down or the network link is being attacked. -

-
-
-
Must-Staple
-

- Caddy can be configured to obtain Must-Staple certificates, which requires that certificate to always have the OCSP response stapled. -

-
-
-
Background Updates
-

- Unlike other web servers, Caddy updates OCSP responses in the background, asynchronously of any requests, well before their expiration. -

-
-
-
Pre-Validated
-

- An OCSP response will not be stapled unless it checks out for validity first, to make sure it's something clients will accept. -

-
-
-
Revocation Handling
-

- If a managed certificate is discovered by OCSP to be revoked, Caddy will automatically try to replace the certificate. -

-
-
- -

ACME Protocol

-
-
-
HTTP Challenge
-

- Caddy can solve the HTTP challenge to obtain certificates. You can also configure Caddy to proxy these challenges to other processes. -

-
-
-
TLS-ALPN Challenge
-

- Caddy solves the TLS-ALPN challenge which happens on port 443 and does not require opening port 80 at all. -

-
-
-
Fleet Coordination
-

- Caddy coordinates the obtaining and renewing of certificates in cluster configurations for both HTTP and TLS-ALPN challenges! -

-
-
-
DNS Challenge
-

- Caddy solves the DNS challenge which does not involve opening any ports on the machine. There are integrations for all major DNS providers! -

-
-
-
Revocation
-

- If one of your private keys becomes compromised, you can use Caddy to easily revoke the affected certificates. -

-
-
-
Customizable CA
-

- Caddy is designed to be used with any ACME-compatible certificate authority, which you can customize with a single command line flag. -

-
-
-
Robust to Failures
-

- Caddy is the only web server and only major ACME client that was not disrupted by CA changes and outages, or OCSP responder hiccups. -

-
-
-
- - - - - -
-

HTTP Server

-

- Caddy's HTTP server has a wide array of modern features, high performance, and is easy to deploy. -

- -

Site Features

-
-
-
Directory Browsing
-

- List files and folders with Caddy's attractive, practical design or according to your own custom template. -

-
-
-
Virtual Hosts
-

- Serve multiple sites from the same IP address with the Caddyfile. -

-
-
-
Configurable Binding
-

- You can select which network interfaces to which you bind the listener, giving you more access control over your site. -

-
-
-
Markdown
-

- Let Caddy render your Markdown files as HTML on-the-fly. You can embed your Markdown in a template and parse out front matter. -

-
-
-
Templates
-

- A powerful and improved alternative to Server-Side Includes, templates allow you to make semi-dynamic sites quickly and easily. -

-
-
-
Custom Error Pages
-

- Show user-friendly error pages when things go wrong, or write the error details to the browser for dev environments. -

-
-
-
Logging
-

- Caddy takes copious notes according to your favorite log format. Log errors and requests to a file, stdout/stderr, or a local or remote system log. -

-
- - -
-
Request Size Limits
-

- You can limit the size of request bodies that go through Caddy to prevent abuse of your network bandwidth. -

-
-
-
Timeouts
-

- Enabling timeouts can be a good idea when your server may be prone to slowloris attacks or you want to free up resources from slow networks. -

-
-
- -

Web Protocols

-
-
-
HTTP/1.1
-

- Still commonly used in plaintext, development, and debug environments, Caddy has solid support for HTTP/1.1. -

-
-
-
HTTP/2
-

- It's time for a faster web. Caddy uses HTTP/2 right out of the box. No thought required. HTTP/1.1 is still used when clients don't support HTTP/2. -

-
-
-
HTTP/3
-

- With the IETF-standard-draft version of QUIC, sites load faster and connections aren't dropped when switching networks. -

-
-
-
WebSockets
-

- Caddy proxies WebSocket upgrades with ease. -

-
-
-
IPv6
-

- Caddy supports both IPv4 and IPv6. In fact, Caddy runs full well in an IPv6 environment without extra configuration. -

-
-
-
FastCGI
-

- Serve your PHP site behind Caddy securely with just one simple line of configuration. You can even specify multiple backends. -

-
-
- -

HTTP Spec

-
- -
-
Basic Authentication
-

- Protect areas of your site with HTTP basic auth. It's simple to use and secure over HTTPS for most purposes. -

-
-
-
Redirects
-

- Caddy can issue HTTP redirects with any 3xx status code, including redirects using <meta> tags if you prefer. -

-
-
-
Headers
-

- Customize the response headers so that some headers are removed or others are added. -

-
-
- -

Reverse Proxy

-
-
-
Basic Proxying
-

- Caddy can act as a reverse proxy for HTTP requests. You can also proxy transparently (preserve the original Host header) with one line of config. -

-
-
-
Load Balancing
-

- Proxy to multiple backends using a load balancing policy of your choice: random, least connections, round robin, IP hash, or header. -

-
-
-
SSL Termination
-

- Caddy is frequently used as a TLS terminator because of its powerful TLS features. -

-
-
-
WebSocket Proxy
-

- Caddy's proxy middleware is capable of proxying websocket connections to backends as well. -

-
-
-
Health Checks
-

- Caddy marks backends in trouble as unhealthy, and you can configure health check paths, intervals, and timeouts for optimal performance. -

-
-
-
Retries
-

- When a request to a backend fails to connect, Caddy will try the request with other backends until one that is online accepts the connection. -

-
-
-
Header Controls
-

- By default, most headers will be carried through, but you can control which headers flow upstream and downstream. -

-
- -
-
Dynamic Backends
-

- Proxy to arbitrary backends based on request parameters such as parts of the domain name or header values. -

-
-
- -

Amenities

-
-
-
Clean URIs
-

- Elegantly serve files without needing the extension present in the URL. These look nicer to visitors and are easy to configure. -

-
-
-
Rewrites
-

- Caddy has powerful request URI rewriting capabilities that support regular expressions, conditionals, and dynamic values. -

-
-
-
Response Status Codes
-

- Send a certain status code for certain requests. -

-
-
-
Compression
-

- Compress content on-the-fly using gzip, Zstandard, or brotli. -

-
-
-
- -
-
- Download - Documentation - Forum +
+
+
+

+
+
The
+ Ultimate Server +
+
+ makes your sites more secure, more reliable, and more scalable than any other solution. +
+

+ +
+ Download + Docs + +
+
+
+
+
+
+ Watch in real-time as Caddy serves HTTPS in < 1 minute. +
+
+
+
+ +
+ +

Sponsored by leaders

+ + + + +
+ + + +
-
+
+ +
+
+ Every
+ site on
+ HTTPS +
+

+ By default, Caddy automatically obtains and renews TLS certificates for all your sites. +

+ +
+
+

HTTPS/TLS for custom domains

+

+ The secret sauce of almost every white-label SaaS is Caddy's original On-Demand TLS feature. Grow your SaaS business by orders of magnitude with ease! +

+
+
+

Dynamically provision certificates

+

+ With On-Demand TLS, only Caddy obtains, renews, and maintains certificates on-the-fly during TLS handshakes. Perfect for customer-owned domains. +

+
+
+

Massively scale your TLS

+

+ Other web servers and scripted certificate tools fall over with hundreds of thousands of sites or thousands of instances. Caddy is designed to manage certificates reliably at this scale. +

+
+
+ +
+
+

sponsored by users like you

+

+ Caddy is free software and relies on sponsorships to survive. Not just donations: sponsorships ensure ongoing development and provide your business with tangible benefits. +

+ See sponsorships +
+
+
+ +
+
+
+

The most advanced HTTPS server in the world

+
+
+
+ +
+
+

All you need for TLS and PKI 🔐

+

+ Caddy securely serves all sites with TLS by default. It can also manage your internal PKI for you across a fleet of servers and clients. +

+
+
+

On-line config API ⚡️

+

+ Caddy's native configuration is a JSON document that you can export and manipulate with a RESTful config API. +

+
+
+

PCI, HIPAA, and NIST compliant ✅

+

+ Caddy's TLS defaults are secure and pass PCI, HIPAA, and NIST compliance requirements. Yes, defaults: no hassle required. +

+
+
+

HTTPS for localhost 🏠

+

+ We mean it when we say Caddy serves every site on HTTPS. Even localhost and internal IPs are served with TLS using the intermediate of a fully-automated, self-managed CA that is automatically installed into most local trust stores. +

+
+
+

Cluster coordination 🌐

+

+ Simply configure multiple Caddy instances with the same storage, and they will automatically coordinate certificate management as a fleet and share resources such as keys and OCSP staples! +

+
+
+

Fewer moving parts ⚙️

+

+ Simplify your infrastructure! Caddy saves money, increases developer productivity, and reduces problems in production. +

+
+
+ +
+

Experience it

+

+ Discover Caddy's automagic HTTPS features with our hosted demo. +

+

+ Point DNS records for any subdomain named caddydemo to either: +

+

+ + CNAME + demo.caddyserver.com + +

+

+ or: +

+

+ + A + 138.68.4.62 + + + AAAA + 2604:a880:2:d0::9dd:9001 + +

+

+ Then visit it in your browser. +

+

+ You'll notice how Caddy provisions a certificate for your domain automatically. +

+
+

+ Not working? Make sure to use a direct subdomain of a registered domain, not a "sub-subdomain." + Verify you have created the public DNS records shown above with the correct values. + You may have to allow time for propagation. Consult your DNS provider's documentation or support for assistance. + Your browser/client must set the TLS ServerName indication (most do). +

+

+ Example subdomains that could work: caddydemo.example.net, caddydemo.example.com.au +

+

+ Caddy is capable of serving TLS for any domains and IPs. This demo is intentionally restricted. +

+
+
+
+
+ +
+
+ +

Deploy your own PKI with Caddy

+

+ Not only is Caddy the industry leader in certificate automation, it also sports a fully-featured PKI suite for your own fully-automated internal PKI and private CAs. +

+ +

+ Powered by open source Smallstep libraries, Caddy becomes a self-managing certificate authority. +

+ + +
+
+
+ {{ markdown (include "/includes/examples/local-https.md") }} +
+
+
+

Internal and localhost certificates

+

+ If you configure sites with local or internal addresses, Caddy will serve them over HTTPS using a locally-trusted certificate authority with short-lived, auto-renewing certificates. It even offers to install your unique root into your local trust stores for you. +

+ Smallstep +
+
+ +
+
+

Make and use your own CAs

+

+ Caddy lets you define as many CAs as you need. Root and intermediate keys are generated automatically, and intermediates are renewed before they expire. +

+

+ Deploy an instance to act as an ACME server. Then other Caddy instances can use it for their certificates. +

+
+
+
+ {{ markdown (include "/includes/examples/custom-ca.md") }} +
+
+
+ +
+
+
+ {{ markdown (include "/includes/examples/json-automate-certs.md") }} +
+
+
+

Keep certificates renewed

+

+ Caddy is more than just a web server. For example, this config is all it takes to obtain and renew certificates for a set of domain names. +

+

+ Additional config can be written to wire up certificate maintenance events, which can then be used to integrate with external scripts and tooling. +

+ +
+
+ + + + +
+
+ +
+
+

Recommended by experts

+

+ Academic and industry experts recommend Caddy, which has been cited in peer-reviewed journals for its security defaults, best practices, and its uniquely advanced feature set. +

+
+
+ +

+ "Servers running Caddy exhibit nearly ubiquitous HTTPS deployment and use modern TLS configurations. ... We hope to see other popular server software follow Caddy's lead." +

+

+ —Josh Aas, Richard Barnes, Benton Case, Zakir Durumeric, Peter Eckersley, Alan Flores-López, J. Alex Halderman, Jacob Hoffman-Andrews, James Kasten, Eric Rescorla, Seth Schoen, and Brad Warren. 2019. Let's Encrypt: An Automated Certificate Authority to Encrypt the Entire Web. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (CCS '19). Association for Computing Machinery, New York, NY, USA, 2473–2487. https://doi.org/10.1145/3319535.3363192 +

+
+
+ +

+ "TLS must be enabled by default ... and the Caddy web server is a good and usable example." +

+

+ —Katharina Krombholz, Wilfried Mayer, Martin Schmiedecker, and Edgar Weippl. 2017. "I Have No Idea What I'm Doing" - On the Usability of Deploying HTTPS. In 26th USENIX Security Symposium (USENIX Security 17), USENIX Association, Vancouver, BC, 1339-1356. Retrieved from https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/krombholz +

+
+
+ +

+ "No popular server software does [session ticket key rotation], with the exception of Caddy." +

+

+ —Drew Springall, Zakir Durumeric, and J. Alex Halderman. 2016. Measuring the Security Harm of TLS Crypto Shortcuts. In Proceedings of the 2016 Internet Measurement Conference (IMC '16), Association for Computing Machinery, Santa Monica, California, USA, 33-47. https://doi.org/10.1145/2987443.2987480 +

+
+
+
+
+ +
+
+

A forward-thinking reverse proxy

+

+ Caddy's proxy was designed to be as forward-compatible as possible and has major batteries included: load balancing, active and passive health checks, dynamic upstreams, retries, pluggable transports, and of course, best-in-class TLS security. +

+ + +
+
+
+

Proxy HTTP, FastCGI, WebSockets, and more

+

+ Capable of proxying HTTP and HTTPS, but also WebSockets, gRPC, FastCGI (usually PHP), and more! The underlying transport module is extensible for any custom way to generate an HTTP response. +

+
+
+

Dynamic backends

+

+ Provide Caddy with a static list of backends or enable a module to retrieve backends dynamically during each request: ideal for rapidly changing environments. Caddy flows with your infrastructure! +

+
+
+

High availability

+

+ Caddy comes with a whole suite of high availability (HA) features: advanced health checking, graceful (hitless) config changes, circuit breaking, load limiting, on-line retries, and more. The best part? It's all free. No enterprise-level paywalls. +

+
+
+
+
+ {{ markdown (include "/includes/examples/proxy.md") }} +
+
+
+ +
+
+
+

software assurance

+

+ Without sponsorships, Caddy could stop being developed at any time. + With sponsorships, you gain peace of mind knowing that the project will continue to be developed, along with tangible benefits like private support and training. +

+ See sponsorships +
+
+
+ +
+
+ + +

Production-grade static file server

+

+ Serving static files is a tried-and-true method of delivering sites to numerous clients efficiently. Caddy has a robust file server that can be combined with other middleware features for the ultimate effortless website. +

+ + +
+
+
+

Compression

+

+ Caddy can compress files on-the-fly or serve precompressed files for extra performance. Caddy is also the first web server to support Zstandard encoding. +

+
+
+

Virtual file systems

+

+ Serve your static site from anything: the local file system, remote cloud storage, a database, or even embedded in the server binary! +

+
+
+

Range requests, Etags, and more

+

+ Unlike many ad-hoc file servers intended for temporary local development, Caddy fully supports Range requests, Etags, and a full production feature set. +

+
+
+

Directory file browser

+

+ If a directory without an index file is requested, Caddy can show an elegant file browser with breadcrumb nav, file size visualizations, filetype icons, and a grid view. +

+
+
+
+
+ {{ markdown (include "/includes/examples/file-server.md") }} +
+
+
+ +
+
+ +
+
+ +
+
+
+
+ +
+
+

Flexible configuration compatible with any workflow

+

+ Configure your server your way. Caddy's native configuration format is JSON, and with Caddy's config adapters, you can use any config format you prefer. All configuration is posted through a RESTful admin API, and Caddy's CLI helps you work with config files easily. +

+ + +
+
+
+ $ caddy start --config caddy.json + +$ curl localhost:2019/id/my_handler \ + -X PATCH \ + -H "Content-Type: application/json" \ + -d '{ + "handler": "static_response", + "body": "Work smarter, not harder." + }' + +$ curl localhost:2019/config/ | jq
 +
+
+
+

JSON config API

+

+ Caddy's native config format is JSON, giving you incredible power and flexibility for automated, large-scale deployments. +

+ Make dynamic config changes through an intuitive, programmable REST API that offers ACID guarantees. It is also safely scoped, meaning that the URI path restricts changes, making it impossible to accidentally alter other parts of your config. +

+ + +
+
+ + +
+
+

Caddyfile

+

+ Although JSON offers ultimate control, most people prefer to use a Caddyfile because it lets you get a production-ready site up and running in just a few hand-written lines. It's not uncommon for Caddyfiles to be just ~15-25% the size of a less-capable nginx config. +

+
+
+
+ {{ markdown (include "/includes/examples/website-caddyfile.md") }} +
Actual config used by this site.
+
+
+
+ + +
+
+
+ $ caddy run \ + --config nginx.conf \ + --adapter nginx
 +
+
+
+

Config adapters

+

+ Power Caddy with anything, even NGINX config files! +

+

+ With first-class support for config adaptation, you can configure your web server with your favorite format: YAML, TOML, CUE, NGINX, HCL, Dhall, JSON with comments, or even a MySQL database... or anything else. The Caddyfile is a built-in config adapter. +

+ + +
+
+
+
+
+
+

Unparalleled extensibility

+

+ Caddy is the only server in the world with its novel, modular architecture. At its core, Caddy is a configuration manager that runs apps like an HTTP server, internal certificate authority, TLS certificate manager, process supervisor, and more. +

+

+ And because of its unique design, we can offer unlimited features without bloating the code base. Only compile in what you need. +

+
+
+

Unlimited power

+

+ Nearly every part of the config that "does something" is pluggable. Caddy offers unlimited capabilities in such a lean package. +

+
+
+

Native CPU performance

+

+ No RPC calls or flimsy dependency management. Plugins are compiled into the static binary, making successful deployments certain and runtimes blazing fast. +

+
+
+

Easy to develop

+

+ Writing Caddy plugins is as easy as writing a Go package. It's a comfortable and familiar process for any Go programmer. +

+
+
+
+
+
+
+

The gold standard web server

+

+ Caddy has the most robust TLS stack on the market. With stronger memory safety guarantees than OpenSSL (Apache & NGINX) and more advanced certificate automation logic than any other server or utility, Caddy keeps your sites online through problems when other servers... won't. +

+

+ Caddy was the first server to fully automate public certificate management—so we've been doing this longer than anyone. With more than 50 million certificates under management, Caddy has set the gold standard for other servers to live up to. +

+
+
+

OCSP stapling saves the day

+

+ Caddy automatically staples OCSP responses and caches them to weather outages. In 2018, many popular sites went down for users of mainstream browsers because crucial OCSP infrastructure had an extended outage. Only Caddy staples and caches OCSP responses by default, so all Caddy sites were unaffected. +

+
+
+

On guard against revocation

+

+ In 2020, a mass certificate revocation event left many sysadmins scrambling to renew their certificates ahead of schedule. Caddy automatically renews certificates that get revoked, and all Caddy sites were unaffected. (This was before ARI existed.) +

+
+
+

Stands tall during audits

+

+ Companies have deployed Caddy in front of their site just hours before important audits—potentially saving their compliance status—because of Caddy's safe defaults and "batteries included" approach. +

+
+
+
+
+
+
+

Take everyone's word for it

+

+ We're biased. But Caddy is widely relied upon and praised by a diverse global user base because of its ease of use, secure defaults, powerful feature set, and business-changing cost reductions. +

+
+
+
+
+
+
+
+
+
+ +
{{include "/includes/footer.html"}} + + + + diff --git a/src/old/includes/account/head.html b/src/old/includes/account/head.html new file mode 100644 index 0000000..2c9e4d9 --- /dev/null +++ b/src/old/includes/account/head.html @@ -0,0 +1,8 @@ +{{define "account-head"}} + {{import "/old/includes/head.html"}} + {{template "head"}} + + + + +{{end}} diff --git a/src/includes/account/nav.html b/src/old/includes/account/nav.html similarity index 81% rename from src/includes/account/nav.html rename to src/old/includes/account/nav.html index 60b2d6c..cf5afd5 100644 --- a/src/includes/account/nav.html +++ b/src/old/includes/account/nav.html @@ -1,6 +1,6 @@