TLDR: When calling caddy run (or maybe a new command? or a flag?) on a directory with a Caddyfile Caddy shouldn't try to start listening on the global localhost:2019 port, it should just run as a one-off thing like caddy file-server.
I'm not sure if I'm getting this all wrong, but I have a global Caddy server in my development machine running at all times, managed by systemd and with the main config loaded from a JSON file at /etc/caddy.json. Whenever I want to deploy more "permanent" stuff I edit that file and reload.
However, in independent directories I'm able to run caddy file-server or caddy reverse-proxy and get an independent Caddy server running on these places for quick things.
Sometimes, however, I want slightly more complex stuff on these rogue directories, like having both a file server and a reverse proxy, then I can write a Caddyfile -- but my knowledge of how to write a Caddyfile is actually useless because if I try to run it I get
2020/04/27 01:33:49.784 INFO using adjacent Caddyfile
run: loading initial config: loading new config: starting caddy administration endpoint:
listen tcp 127.0.0.1:2019: bind: address already in use
Which means I must add my quick demo server to the global Caddy instance instead of being able to serve a fileserver/reverseproxy on localhost using the power of a Caddyfile to configure it.
I don't really understand where do Caddyfiles fit now -- they can't fit on individual directories, but also can't fit for master Caddy (unless you write a Caddyfile just for it to be transformed that into a JSON config).
You're looking for the admin global option to change which port/address Caddy uses for the admin endpoint. You can also turn it off entirely if you don't need it.
See here: https://caddyserver.com/docs/caddyfile/options
{
admin off
}
... rest of your Caddyfile
Next time, please ask your usage questions on the Caddy community forums. We prefer to keep the GitHub issue board for bugs and feature requests.
@fiatjaf To clarify, your problem has nothing to do with Caddyfiles. It's just that Caddy's admin endpoint binds to port 2019. If you run more than instance, the second one will fail since the socket is already in use. You can disable it in your config, as Francis showed, or just change the socket it binds to.
Thank you very much and sorry for the spam.
It's not spam :) Hope that helped!
Yeah no worries, questions just means more people are interested in Caddy, and we're all about that. It's just easier to manage things with that clear delineation between support and development.
Most helpful comment
@fiatjaf To clarify, your problem has nothing to do with Caddyfiles. It's just that Caddy's admin endpoint binds to port 2019. If you run more than instance, the second one will fail since the socket is already in use. You can disable it in your config, as Francis showed, or just change the socket it binds to.