From 993012084941f324bea3909f11387adaedda160e Mon Sep 17 00:00:00 2001 From: YAKSH BARIYA Date: Wed, 30 Jun 2021 11:16:05 +0530 Subject: [PATCH 01/19] docs: Caddy is also available on Termux (#170) --- src/docs/markdown/install.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/src/docs/markdown/install.md b/src/docs/markdown/install.md index e42e471..395a587 100644 --- a/src/docs/markdown/install.md +++ b/src/docs/markdown/install.md @@ -27,6 +27,7 @@ This page describes various methods for installing Caddy on your system. - [Webi](#webi) - [Chocolatey](#chocolatey) - [Ansible](#ansible) +- [Termux](#termux) ## Static binaries @@ -211,3 +212,13 @@ _Note: This is a community-maintained installation method._
scoop install caddy
[**View the Scoop manifest**](https://github.com/ScoopInstaller/Main/blob/master/bucket/caddy.json) + + +## Termux + +_Note: This is a community-maintained installation method._ + +
pkg install caddy
+ +[**View the Termux build.sh file**](https://github.com/termux/termux-packages/blob/master/packages/caddy/build.sh) + From 1a8d8fbee6f4bf654a7414bd4c5a558e204cc6e4 Mon Sep 17 00:00:00 2001 From: Francis Lavoie Date: Wed, 30 Jun 2021 01:47:26 -0400 Subject: [PATCH 02/19] docs: Add `scoop` to install TOC --- src/docs/markdown/install.md | 1 + 1 file changed, 1 insertion(+) diff --git a/src/docs/markdown/install.md b/src/docs/markdown/install.md index 395a587..712e9a3 100644 --- a/src/docs/markdown/install.md +++ b/src/docs/markdown/install.md @@ -27,6 +27,7 @@ This page describes various methods for installing Caddy on your system. - [Webi](#webi) - [Chocolatey](#chocolatey) - [Ansible](#ansible) +- [Scoop](#scoop) - [Termux](#termux) From 10a451478512c0f1391566433c39cc89e70da381 Mon Sep 17 00:00:00 2001 From: Basil Hendroff <63370329+basilhendroff@users.noreply.github.com> Date: Wed, 30 Jun 2021 13:49:23 +0800 Subject: [PATCH 03/19] docs: Update command-line.md TOC (#174) Co-authored-by: Matt Holt Co-authored-by: Francis Lavoie --- src/docs/markdown/command-line.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/docs/markdown/command-line.md b/src/docs/markdown/command-line.md index 160349e..6b7ea4f 100644 --- a/src/docs/markdown/command-line.md +++ b/src/docs/markdown/command-line.md @@ -23,6 +23,9 @@ The ellipses `...` indicates a continuation, i.e. one or more parameters. - **[caddy adapt](#caddy-adapt)** Adapts a config document to native JSON +- **[caddy build-info](#caddy-build-info)** + Prints build information + - **[caddy environ](#caddy-environ)** Prints the environment @@ -62,6 +65,9 @@ The ellipses `...` indicates a continuation, i.e. one or more parameters. - **[caddy untrust](#caddy-untrust)** Untrusts a certificate from local trust store(s) +- **[caddy upgrade](#caddy-upgrade)** + Upgrades Caddy to the latest release + - **[caddy validate](#caddy-validate)** Tests whether a config file is valid From e24691fe37efce2f57db603910b16372da0a50e9 Mon Sep 17 00:00:00 2001 From: Daniel Abromeit aka Abro Date: Thu, 1 Jul 2021 18:39:27 +0200 Subject: [PATCH 04/19] docs: Fix two little typos (header, metrics) (#179) --- src/docs/markdown/caddyfile/directives/header.md | 2 +- src/docs/markdown/metrics.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/src/docs/markdown/caddyfile/directives/header.md b/src/docs/markdown/caddyfile/directives/header.md index 33683ab..e36e92f 100644 --- a/src/docs/markdown/caddyfile/directives/header.md +++ b/src/docs/markdown/caddyfile/directives/header.md @@ -6,7 +6,7 @@ title: header (Caddyfile directive) Manipulates HTTP header fields on the response. It can set, add, and delete header values, or perform replacements using regular expressions. -By default, header operations are performed immediately unless any of the headers are being deleted (`-` prefix) or setting a defualt value (`?` prefix). In those cases, the header operations are automatically deferred until the time they are being written to the client. +By default, header operations are performed immediately unless any of the headers are being deleted (`-` prefix) or setting a default value (`?` prefix). In those cases, the header operations are automatically deferred until the time they are being written to the client. ## Syntax diff --git a/src/docs/markdown/metrics.md b/src/docs/markdown/metrics.md index ca4c366..155470f 100644 --- a/src/docs/markdown/metrics.md +++ b/src/docs/markdown/metrics.md @@ -85,7 +85,7 @@ automatically by the Prometheus Go Client. They are prefixed with `go_*` and Note that the `process_*` metrics are only collected on Linux and Windows. See the documentation for the [Go Collector](https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#NewGoCollector), -[Process Colletor](https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#NewProcessCollector), +[Process Collector](https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#NewProcessCollector), and [BuildInfo Collector](https://pkg.go.dev/github.com/prometheus/client_golang/prometheus#NewBuildInfoCollector). ### Admin API metrics From 56e1517c0f1e2b7ca838ac49c8f6916cab9d8934 Mon Sep 17 00:00:00 2001 From: Francis Lavoie Date: Thu, 1 Jul 2021 19:10:05 -0400 Subject: [PATCH 05/19] docs: Move `key_type` to the correct place, minor adjustments --- src/docs/markdown/caddyfile/directives/tls.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/src/docs/markdown/caddyfile/directives/tls.md b/src/docs/markdown/caddyfile/directives/tls.md index 1f3252b..8d4b565 100644 --- a/src/docs/markdown/caddyfile/directives/tls.md +++ b/src/docs/markdown/caddyfile/directives/tls.md @@ -22,6 +22,7 @@ tls [internal|] | [ ] { load ca ca_root + key_type ed25519|p256|p384|rsa2048|rsa4096 dns [] resolvers eab @@ -70,6 +71,7 @@ tls [internal|] | [ ] { - **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_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) - **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. - **eab** configures ACME external account binding (EAB) for this site, using the key ID and MAC key provided by your CA. @@ -109,7 +111,6 @@ Obtains certificates using the ACME protocol. test_dir email timeout - key_type ed25519|p256|p384|rsa2048|rsa4096 disable_http_challenge disable_tlsalpn_challenge alt_http_port @@ -129,8 +130,7 @@ Obtains certificates using the ACME protocol. - **dir** is the URL to the ACME CA's directory. Default: `https://acme-v02.api.letsencrypt.org/directory` - **test_dir** is an optional fallback directory to use when retrying challenges; if all challenges fail, this endpoint will be used during retries; useful if a CA has a staging endpoint where you want to avoid rate limits on their production endpoint. Default: `https://acme-staging-v02.api.letsencrypt.org/directory` - **email** is the ACME account contact email address. -- **timeout** is how long to wait before timing out an ACME operation. -- **key_type** is the type of key to use when generating CSRs. Only set this if you have a specific requirement. +- **timeout** is a [duration value](/docs/conventions#durations) that sets how long to wait before timing out an ACME operation. - **disable_http_challenge** will disable the HTTP challenge. - **disable_tlsalpn_challenge** will disable the TLS-ALPN challenge. - **alt_http_port** is an alternate port on which to serve the HTTP challenge; it has to happen on port 80 so you must forward packets to this alternate port. @@ -138,7 +138,7 @@ Obtains certificates using the ACME protocol. - **eab** specifies an External Account Binding which may be required with some ACME CAs. - **trusted_roots** is one or more root certificates (as PEM filenames) to trust when connecting to the ACME CA server. - **dns** configures the DNS challenge. -- **propagation_timeout** is a [duration value](/docs/conventions#durations) that sets how long to wait for DNS TXT records to propagate. Default 2 minutes. +- **propagation_timeout** is a [duration value](/docs/conventions#durations) that sets how long to wait for DNS TXT records to propagate when using the DNS challenge. Default 2 minutes. - **resolvers** customizes the DNS resolvers used when performing the DNS challenge; these take precedence over system resolvers or any default ones. - **preferred_chains** specifies which certificate chains Caddy should prefer; useful if your CA provides multiple chains. Use one of the following options: - **smallest** will tell Caddy to prefer chains with the fewest amount of bytes. From 60bc4ee7c3c95d53fda966aab4a2d79511365ba4 Mon Sep 17 00:00:00 2001 From: Jon Cram Date: Wed, 7 Jul 2021 15:20:59 +0100 Subject: [PATCH 06/19] docs: reverse_proxy typo "tranport" -> "transport" (#182) The reverse_proxy directive docs contained a TOC featuring the line "The fastcgi tranport". Changed "tranport" to "transport". --- src/docs/markdown/caddyfile/directives/reverse_proxy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/markdown/caddyfile/directives/reverse_proxy.md b/src/docs/markdown/caddyfile/directives/reverse_proxy.md index 40936e2..4aa318c 100644 --- a/src/docs/markdown/caddyfile/directives/reverse_proxy.md +++ b/src/docs/markdown/caddyfile/directives/reverse_proxy.md @@ -15,7 +15,7 @@ Proxies requests to one or more backends with configurable transport, load balan - [Headers](#headers) - [Transports](#transports) - [The `http` transport](#the-http-transport) - - [The `fastcgi` tranport](#the-fastcgi-transport) + - [The `fastcgi` transport](#the-fastcgi-transport) - [Intercepting responses](#intercepting-responses) - [Examples](#examples) From 5b216fea49a93108282f87814c4c1f00a3f031f6 Mon Sep 17 00:00:00 2001 From: Nya Meteor <26038696+nyameteor@users.noreply.github.com> Date: Mon, 12 Jul 2021 22:31:25 +0800 Subject: [PATCH 07/19] docs: Fix an incorrect URL (route) (#184) --- src/docs/markdown/caddyfile/directives/route.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/docs/markdown/caddyfile/directives/route.md b/src/docs/markdown/caddyfile/directives/route.md index 0ae9dc8..7e76375 100644 --- a/src/docs/markdown/caddyfile/directives/route.md +++ b/src/docs/markdown/caddyfile/directives/route.md @@ -67,7 +67,7 @@ And now `file_server` will be chained in before `redir` because the order is tak There are other directives that can wrap HTTP handler directives, but each has its use depending on the behavior you want to convey: -- [`handle`](route) wraps other directives like `route` does, but with two distinctions: 1) handle blocks are mutually exclusive to each other, and 2) directives with a handle are [re-ordered]([directive order](/docs/caddyfile/directives#directive-order) normally. +- [`handle`](handle) wraps other directives like `route` does, but with two distinctions: 1) handle blocks are mutually exclusive to each other, and 2) directives with a handle are [re-ordered]([directive order](/docs/caddyfile/directives#directive-order) normally. - [`handle_path`](handle_path) does the same as `handle`, but it strips a prefix from the request before running its handlers. - [`handle_errors`](handle_errors) is like `handle`, but is only invoked when Caddy encounters an error during request handling. From 8fded0b38e59c88372ac1193f2bfcf0db81404d3 Mon Sep 17 00:00:00 2001 From: Tobias Gruetzmacher Date: Mon, 12 Jul 2021 18:56:34 +0200 Subject: [PATCH 08/19] docs: Remove usage of apt-key (#177) --- src/docs/markdown/install.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/docs/markdown/install.md b/src/docs/markdown/install.md index 712e9a3..9278f8e 100644 --- a/src/docs/markdown/install.md +++ b/src/docs/markdown/install.md @@ -48,7 +48,7 @@ This package also comes with a `caddy-api` systemd service using our official [` Stable releases:
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
-curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo apt-key add -
+curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo tee /etc/apt/trusted.gpg.d/caddy-stable.asc
 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
@@ -56,7 +56,7 @@ Stable releases: Testing releases (includes betas and release candidates):
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
-curl -1sLf 'https://dl.cloudsmith.io/public/caddy/testing/gpg.key' | sudo apt-key add -
+curl -1sLf 'https://dl.cloudsmith.io/public/caddy/testing/gpg.key' | sudo tee /etc/apt/trusted.gpg.d/caddy-testing.asc
 curl -1sLf 'https://dl.cloudsmith.io/public/caddy/testing/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-testing.list
 sudo apt update
 sudo apt install caddy
From 275cce9403cc27f128dc3fcc9229c597660d60b8 Mon Sep 17 00:00:00 2001 From: Tobias Gruetzmacher Date: Mon, 19 Jul 2021 16:07:20 +0200 Subject: [PATCH 09/19] docs: Add Windows service instructions (#176) --- src/docs/markdown/install.md | 49 ++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/src/docs/markdown/install.md b/src/docs/markdown/install.md index 9278f8e..2ed8c77 100644 --- a/src/docs/markdown/install.md +++ b/src/docs/markdown/install.md @@ -29,6 +29,7 @@ This page describes various methods for installing Caddy on your system. - [Ansible](#ansible) - [Scoop](#scoop) - [Termux](#termux) +- [Windows service](#windows-service) ## Static binaries @@ -223,3 +224,51 @@ _Note: This is a community-maintained installation method._ [**View the Termux build.sh file**](https://github.com/termux/termux-packages/blob/master/packages/caddy/build.sh) + +## Windows service + +_Note: This is a community-maintained installation method._ + +Install Caddy as a service on Windows with these instructions. + +**Requirements:** + +- `caddy.exe` binary that you [downloaded](/download) or [built from source](/docs/build) +- Any exe from the latest release of the + [WinSW](https://github.com/winsw/winsw/releases/latest) service wrapper (Stay + on a v2.x release for now) + +Put all files into a service directory. In the following examples, we use `c:\caddy`. + +Rename the WinSW exe file to `caddy-service.exe`. + +Add a `caddy-service.xml` in the directory: + +
<service>
+  <id>caddy</id>
+  <!-- Display name of the service -->
+  <name>Caddy Web Server (powered by WinSW)</name>
+  <!-- Service description -->
+  <description>Caddy Web Server (https://caddyserver.com/)</description>
+  <executable>%BASE%\caddy.exe</executable>
+  <arguments>run</arguments>
+  <log mode="roll-by-time">
+    <pattern>yyyy-MM-dd</pattern>
+  </log>
+</service>
+
+ +You can now install the service using: +
caddy-service install
+ +You might want to start the Windows Services Console to see if the service is runnnig correctly: +
services.msc
+ +Be aware that Windows services cannot be reloaded, so you have to tell caddy directly to relaod: +
caddy reload
+ +Restarting is possible via the normal Windows services commands. + +For customizing the service wrapper, see the [WinSW documentation](https://github.com/winsw/winsw/tree/master#usage) + + From 8a8b96dc86115dff9863b2aae691e60f2dc5978f Mon Sep 17 00:00:00 2001 From: Matthew Holt Date: Wed, 28 Jul 2021 16:56:35 -0600 Subject: [PATCH 10/19] docs: Enhance auto HTTPS page, esp. on-demand TLS --- src/docs/markdown/automatic-https.md | 30 ++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/src/docs/markdown/automatic-https.md b/src/docs/markdown/automatic-https.md index 7e03880..701523f 100644 --- a/src/docs/markdown/automatic-https.md +++ b/src/docs/markdown/automatic-https.md @@ -128,6 +128,8 @@ The first time a root key is used, Caddy will try to install it into the system' After Caddy's root CA is installed, you will see it in your local trust store as "Caddy Local Authority" (unless you've configured a different name). You can uninstall it any time if you wish (the [`caddy untrust`](/docs/command-line#caddy-untrust) command makes this easy). +Note that automatically installing the certificate into the local trust stores is for convenience only and isn't guaranteed to work, especially if containers are being used or if Caddy is being run as an unprivileged system service. Ultimately, if you are relying on internal PKI, it is the system administrator's responsibility to ensure Caddy's root CA is properly added to the necessary trust stores (this is outside the scope of the web server). + ### CA Intermediates @@ -182,22 +184,34 @@ DNS provider support is a community effort. [Learn how to enable the DNS challen ## On-Demand TLS -Caddy pioneered a new technology we call **On-Demand TLS**. Many businesses rely on this feature to scale their TLS deployments at lower cost and without operational headaches when serving tens of thousands of sites. +Caddy pioneered a new technology we call **On-Demand TLS**, which dynamically obtains a new certificate during the first TLS handshake that requires it, rather than at config load. Crucially, this does not require specifying the domain names in your configuration ahead of time. -This unique feature obtains the certificate for a name during the first TLS handshake that requires it, rather than at config load. This is useful if: +Many businesses rely on this unique feature to scale their TLS deployments at lower cost and without operational headaches when serving tens of thousands of sites. -- you do not know all the domain names up front, -- domain names might not be properly configured right away (e.g. DNS records not yet set), -- or you are not in control of the domain names (e.g. they are customer domains). +On-demand TLS is useful if: -When on-demand TLS is enabled, a TLS handshake may trigger maintenance for the relevant certificate. If no existing certificate is available, this process slows down only the initial TLS handshake while a certificate is obtained in the foreground; all other handshakes will not be affected (except those waiting on the same certificate). If an existing certificate can be used, the handshake will complete immediately, and maintenance (i.e. renewal) will happen in the background. +- you do not know all the domain names when you start or reload your server, +- domain names might not be properly configured right away (DNS records not yet set), +- you are not in control of the domain names (e.g. they are customer domains). -You can enable it using the [on_demand](/docs/json/apps/tls/automation/on_demand/) property in your TLS automation config, or the [on_demand Caddyfile subdirective](/docs/caddyfile/directives/tls#syntax). Note that enabling on-demand TLS is separate from configuring how it works. **Important:** To prevent abuse, you should specify rate limits and/or an endpoint that Caddy can query to ask if a certificate is allowed to be obtained for a hostname. +When on-demand TLS is enabled, you do not need to specify the domain names in your config in order to get certificates for them. Instead, when a TLS handshake is received for a server name (SNI) that Caddy does not yet have a certificate for, the handshake is held while Caddy obtains a certificate to use to complete the handshake. The delay is usually only a few seconds, and only that initial handshake is slow. All future handshakes are fast because certificates are cached and reused, and renewals happen in the background. Future handshakes may trigger maintenance for the certificate to keep it renewed, but this maintenance happens in the background if the certificate hasn't expired yet. + +### Using On-Demand TLS + +**In production environments, on-demand TLS must be both enabled and restricted. Enabling without restricting opens your server to attack.** + +Enabling on-demand TLS happens in [TLS automation policies](/docs/json/apps/tls/automation/policies/) if using the JSON config, or [in site blocks with the `tls` directive](/docs/caddyfile/directives/tls) if using the Caddyfile. + +To prevent abuse of this feature, you must configure restrictions. This is done in the [`automation` object of the JSON config](/docs/json/apps/tls/automation/on_demand/), or the [`on_demand_tls` global option](/docs/caddyfile/options#on-demand-tls) of the Caddyfile. Restrictions are "global" and aren't configurable per-site or per-domain. The primary restriction is an "ask" endpoint to which Caddy will send an HTTP request to ask if it has permission to obtain and manage a certificate for the domain in the handshake. This means you will need some internal backend that can, for example, query the accounts table of your database and see if a customer has signed up with that domain name. + +You can also configure rate limits as restrictions, though rate limits alone are not a sufficient protection. Be mindful of how quickly your CA is able to issue certificates. If it takes more than a few seconds, this will negatively impact the user experience (for the first client only). Due to its deferred nature and potential for abuse (if not mitigated through proper configuration), we recommend enabling on-demand TLS only when your actual use case is described above. +[See our wiki article for more information about using on-demand TLS effectively.](https://caddy.community/t/serving-tens-of-thousands-of-domains-over-https-with-caddy/11179) + ## Errors Caddy does its best to continue if errors occur with certificate management. @@ -243,7 +257,7 @@ Before attempting any ACME transactions, Caddy will test the configured storage Caddy can obtain and manage wildcard certificates when it is configured to serve a site with a qualifying wildcard name. A site name qualifies for a wildcard if only its left-most domain label is a wildcard. For example, `*.example.com` qualifies, but these do not: `sub.*.example.com`, `foo*.example.com`, `*bar.example.com`, and `*.*.example.com`. -If using the Caddyfile, Caddy takes site names literally with regards to the certificate subject names. In other words, a site defined as `sub.example.com` will cause Caddy to manage a certificate for `sub.example.com`, and a site defined as `*.example.com` will cause Caddy to manage a wildcard certificate for `*.example.com`. If you need different behavior, the [JSON config](/docs/json/) gives you precise control over certificate subjects and site names ("host matchers"). +If using the Caddyfile, Caddy takes site names literally with regards to the certificate subject names. In other words, a site defined as `sub.example.com` will cause Caddy to manage a certificate for `sub.example.com`, and a site defined as `*.example.com` will cause Caddy to manage a wildcard certificate for `*.example.com`. You can see this demonstrated on our [Common Caddyfile Patterns](/docs/caddyfile/patterns#wildcard-certificates) page. If you need different behavior, the [JSON config](/docs/json/) gives you more precise control over certificate subjects and site names ("host matchers"). 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. From 5f09f05e0825f0835691788699d32698faa55a54 Mon Sep 17 00:00:00 2001 From: Francis Lavoie Date: Wed, 11 Aug 2021 19:08:47 -0400 Subject: [PATCH 11/19] docs: Add new "Keep Caddy Running" page, moved from install.md (#181) * docs: Add new Linux Service page, moved from install.md * Apply suggestions from code review Co-authored-by: Carl George * Add note regarding resetting Exec* * Updates to make the page more generalized Docker * Polish the Windows Service docs a bit Co-authored-by: Carl George --- src/docs/markdown/command-line.md | 2 +- src/docs/markdown/install.md | 128 ++---------------- src/docs/markdown/running.md | 214 ++++++++++++++++++++++++++++++ src/docs/markdown/v2-upgrade.md | 7 +- src/includes/docs-nav.html | 1 + 5 files changed, 229 insertions(+), 123 deletions(-) create mode 100644 src/docs/markdown/running.md diff --git a/src/docs/markdown/command-line.md b/src/docs/markdown/command-line.md index 6b7ea4f..7f577c1 100644 --- a/src/docs/markdown/command-line.md +++ b/src/docs/markdown/command-line.md @@ -311,7 +311,7 @@ Same as [`caddy run`](#caddy-run), but in the background. This command only bloc Note: the flag `--config` doesn't support `-` to read the config from stdin. -Use of this command is discouraged with system services or on Windows. On Windows, the child process will remain attached to the terminal, so closing the window will forcefully stop Caddy, which is not obvious. +Use of this command is discouraged with system services or on Windows. On Windows, the child process will remain attached to the terminal, so closing the window will forcefully stop Caddy, which is not obvious. Consider running Caddy [as a service](/docs/running) instead. Once started, you can use [`caddy stop`](#caddy-stop) or [the /stop API endpoint](/docs/api#post-stop) to exit the background process. diff --git a/src/docs/markdown/install.md b/src/docs/markdown/install.md index 2ed8c77..36f3082 100644 --- a/src/docs/markdown/install.md +++ b/src/docs/markdown/install.md @@ -14,7 +14,6 @@ This page describes various methods for installing Caddy on your system. - [Arch Linux, Manjaro, Parabola](#arch-linux-manjaro-parabola) - [Docker](#docker) - [DigitalOcean](#digitalocean) -- [Linux service](#linux-service)