It’s very important for API users. These users typically make many small changes over time to sometimes very large and complicated Caddy configuration. They want this configured state to persist between restarts and upgrades - if they wanted Caddy to load a whole new config, they would post a whole new config.
Off the top of my head I’m not sure if it’s used as fallback config if you try to hot reload a bad Caddyfile. It might not be necessary for that but even if it is, it’s “persistent enough” for my needs just inside the container without a volume; it’ll stay put until the container is destroyed and recreated anyway.
As I don’t personally use the API myself (I usually keep my configuration inline with Docker inline configs or lucaslorentz/caddy-docker-proxy), I never persist this volume.
The caddy_data:/data volume is obviously quite critical to all users by comparison.
It’s a little ambiguous what you mean here, but just to be clear, yes I expect the JSON to be recreated each time Caddy successfully loads a new config (such as reading in a Caddyfile at startup). But the volume itself definitely shouldn’t be getting created every time you create a container. Docker Compose should definitely be ensuring the volume persists, even through docker compose down.