caddy2 deployment repo
Go to file
David Kebler c34205201a add aws credentials secret 2020-05-17 19:33:35 -07:00
.gitsecret add aws credentials secret 2020-05-17 19:33:35 -07:00
bin add aws credentials secret 2020-05-17 19:33:35 -07:00
conf add aws credentials secret 2020-05-17 19:33:35 -07:00
env add aws credentials secret 2020-05-17 19:33:35 -07:00
filter first commit 2020-05-12 20:07:05 -07:00
scripts first commit 2020-05-12 20:07:05 -07:00
systemd add aws credentials secret 2020-05-17 19:33:35 -07:00
.gitignore add aws credentials secret 2020-05-17 19:33:35 -07:00
README.md add aws credentials secret 2020-05-17 19:33:35 -07:00
caddy add aws credentials secret 2020-05-17 19:33:35 -07:00

README.md

Official service files for systemd

This folder contains the officially-maintained systemd files that should be used as a basis for your own deployments.

⚠️ Always review your service file before using it! Change anything that you need to customize.

Instructions

See our website for installation instructions.

Prerequisites

Running Caddy as a systemd service requires the following:

Group named caddy:

$ groupadd --system caddy

User named caddy with a writeable home folder:

$ useradd --system \
    --gid caddy \
    --create-home \
    --home-dir /var/lib/caddy \
    --shell /usr/sbin/nologin \
    --comment "Caddy web server" \
    caddy

Choosing a service file

  • caddy.service - Use this one if you configure Caddy with a file (for example, the Caddyfile, or a .json file).
  • caddy-api.service - Use this one if you configure Caddy solely through its API.

The two files are identical except for the ExecStart and ExecReload commands.

Important

Caddy receives all configuration through its admin API, even when the command line interface (CLI) is used, which simply wraps up the API calls for you.

Most users will use either config files and the CLI mutually exclusively with the API because it is simpler to have only one source of truth. However, you may wish to provide Caddy an initial "bootstrapping" configuration with a config file, and use the API thereafter.

⚠️ If you provide an initial config file with the --config flag and then update the config using the API, you risk losing your changes if the service is restarted unless you have the --resume flag in your ExecStart command.

Without the --resume flag, the --config flag will overwrite any last-known configuration.

However, it is totally safe and normal to use both the --config and --resume options together if you need to use both a config file and the API. Just be aware that if you update your config file and want to apply those changes, stopping and starting the server is the wrong way to do this. Restarting the service is orthogonal to config changes; this is a unique safety feature that guarantees durability and prevents data loss. If the config file has the latest changes, you should use the reload command instead.