Feature request: --cache-caddyfile / --write-caddyfile
Hi,
I managed to mess up my Caddyfile, but caddy is still running and working -- however, it will certainly break as soon as it's restarted.
This makes me think that it would be a nice thing to have an optional flag like --keep-caddyfile (or make it the default, depending on filesize maybe) that saves Caddyfile as it was when loading it into memory, allowing you to do something like:
caddy --write-caddyfile > Caddyfile
To get back a file on disk equal to what the config was for the currently running instance of caddy.
The closest I've been able to find is curl localhost:2019/config/ but this doesn't exactly seem trivial to get back into a Caddyfile format.
And yes, I know, you're supposed to have backups to restore from. That's what I'm doing, it would just be a nice feature.
Or better: put your config in git.
This isn't in scope for Caddy to solve for you, tbh.
As you've seen, the Caddyfile adapter's job is simply to produce a JSON config, which is what Caddy actually runs with. So at runtime, there's no such thing as Caddyfile, it's just the resulting JSON config that exists.
This isn't in scope for Caddy to solve for you, tbh.
I never said it was, but this kind of attitude combined with obvious off topic solutions is pretty much what I expected.
There's already caddy adapt which converts a Caddyfile to JSON, it doesn't seem obviously "out of scope" to me to have the inverse functionality, but whatever. Feel free to close.
it doesn't seem obviously "out of scope" to me to have the inverse functionality
Easier said than done. There's no canonical translation from JSON to Caddyfile. The translation from Caddyfile is already lossy, so the way back can never be perfect.
Francis' suggestion isn't off-topic. We just receive too many imperfect suggestions based on XY problems, so the first instinct is to drive towards best practice that would invalidate the problem to begin with.
No attitude, just explaining. Like @mohammed90 said, Caddyfile to JSON is a lossy conversion. For example there's no way to recreate the comments, matchers (and their names), site blocks in general, snippets, etc. All those are "magic" that gets collapsed or expanded in conversion, so there's no way to reverse it.
Also typically it's not the server process itself that's doing the adapting, when you run caddy reload it runs a new process that converts your config to JSON then sends it to the running server over the admin API. So the server never sees the Caddyfile and wouldn't be able to back anything up.
Really, it's your responsibility to manage and backup your config, just like with any other piece of software you have.