Consider this Caddyfile:
caddy {
description "Caddy Web Server"
env {
CADDYPATH=value
another_env_var=value2
}
run /home/www { # convenient way to specify the working directory
caddy -log caddy.log
# more commands can be added here
# (commands will not be interpreted like bash; this is not a shell)
}
restart failures {
max 5
delay 10s
}
background
user www-data
group www-data
}
restic {
description "Restic backup"
env inherit { # env is totally empty by default?
RESTIC_REPOSITORY=/home/backup
RESTIC_PASSWORD=my_password
}
run restic backup /home/matt/myfiles
run restic check
}
Running Caddy a -type flag with some value would cause Caddy to read this Caddyfile and act as a process manager of sorts. Much easier to use than other process managers or init systems I’ve used. This is something I’ve been quite interested in myself for some time…
Anyway, this would give the user a lot of control and flexibility over each process, including its environment and failure modes, etc. It won’t be a true init system like init.d or systemd are, so you lose some control over when to actually launch each process (e.g. after the network interfaces come online). But as long as the single Caddy process isn’t run until enough of the system is ready for what you need, it should be fine.
Oh, and a big plus to this is it should work cross-platform (mostly). And a local REST API will be exposed so you can view and manage your processes.
One big question is whether this should be a Caddy server type or a different application entirely. The main benefit would be that we can borrow Caddy’s Caddyfile parser and then we just invent our own CLI, rather than piggybacking off of Caddy’s. But Caddy has a lot of the groundwork laid already, and we can add our own command line flags – even a lot of them – if we want a powerful, robust CLI.
Still working out a lot of details, but I’m opening up this brainstorm to your comments/feedback/requests.