Caddy does not save configs automatically

[touhidurrr]

You're commenting on an issue created during the beta versions of v2.0.0. The issue isn't applicable anymore.

I think any change the user made to the config file should persist. When you install caddy with a package manager globally, the intent should be that it restarts and retains its config on server reboot.

That's already the case.

Originally posted by @mohammed90 in https://github.com/caddyserver/caddy/issues/2903#issuecomment-2156148449

@mohammed90 i am using caddy v2.8.4 and is still facing this issue.

[francislavoie]

What issue? You didn't exactly describe a problem.

Please ask your usage questions on the Caddy community forums. We prefer to keep the GitHub issue board for bugs and feature requests. Don't forget to fill out the thread template so we can help you!

[touhidurrr]

What issue? You didn't exactly describe a problem.

Basically with a fresh installation of caddy with package managers, the config files loaded with caddy reload or caddy adapt is lost when the system is rebooted. Not sure if this happens without package managers also. This can also be reproduced with sudo systemctl restart caddy. I have not tried JSON yet, but the result should be the same.

[francislavoie]

You haven't shown any evidence of that. We need detail. Show logs. Show your config. Show you installed and run Caddy. Those are all questions we need answered before this can be considered a bug. And it's best if you do that via the forums, as requested.

Considering we have 4+ years of evidence from the many thousands of Caddy users that this works for them, this must be user-error (as in, you're doing it wrong). Especially without evidence on your part.

[touhidurrr]

@francislavoie, This might be the reappearance of an issue that I mentioned above. I faced this issue with a fresh Debian VM on Azure and after a lot of searching and finding no solution, fixed it in the way mentioned here https://github.com/caddyserver/caddy/issues/2903#issuecomment-2156123550. Any issue can reappear at any time, if your experience is such then I would suggest closing this issue. Since my problem is fixed I don't want to spend time behind it any additional time behind it, like you don't think this can be an issue without attempting to reproduce it. I simply reported it to take it off of my bucket list so that other users likely facing the same issue as me can find some context. That's all. Thanks for your assistance.

[francislavoie]

You're not describing an actual problem though! You're not showing any evidence! How do you expect us to help you? sigh.

[mholt]

@touhidurrr The linked issue you originally commented on (#2903) is about POSTing new configs through Caddy's API. If you're using caddy reload or systemctl reload caddy (don't use restart unless you want to stop and start the server entirely), that reloads config files, which must be specified using --config (or a Caddyfile in the same folder by default if not specified).

I think any change the user made to the config file should persist.

Changes to config files are outside the scope of Caddy: make sure you save your file when you're done editing it. Has nothing to do with the server.

If you POST a config through the API, the config is persisted to disk and will be automatically reloaded if --resume is given, as mentioned in the API docs:

The latest configuration will be saved to disk after any changes (unless disabled). You can resume the last working config after a restart with caddy run --resume, which guarantees config durability in the event of a power cycle or similar.

I'm attaching a template below with instructions that will help us see eye to eye on the problem you're experiencing. Please fill it out completely so that there's no misunderstanding.

---

Ideally, we need to be able to reproduce the bug in the most minimal way possible using the latest version of Caddy. This allows us to write regression tests to verify the fix is working. If we can't reproduce it, then you'll have to test our changes for us until it's fixed -- and then we can't add test cases, either.

I've attached a template below that will help make this easier and faster! This will require some effort on your part -- please understand that we will be dedicating time to fix the bug you are reporting if you can just help us understand it and reproduce it easily.

This template will ask for some information you've already provided; that's OK, just fill it out the best you can. :+1: I've also included some helpful tips below the template. Feel free to let me know if you have any questions!

Thank you again for your report, we look forward to resolving it!

Template

## 1. Environment

### 1a. Operating system and version

```
paste here
```

### 1b. Caddy version (run `caddy version` or paste commit SHA)

This should be the latest version of Caddy:

```
paste here
```

## 2. Description

### 2a. What happens (briefly explain what is wrong)

### 2b. Why it's a bug (if it's not obvious)

### 2c. Log output

```
paste terminal output or logs here
```

### 2d. Workaround(s)

### 2e. Relevant links

## 3. Tutorial (minimal steps to reproduce the bug)

Instructions -- please heed otherwise we cannot help you (help us help you!)

1. Environment: Please fill out your OS and Caddy versions, even if you don't think they are relevant. (They are always relevant.) If you built Caddy from source, provide the commit SHA and specify your exact Go version.

2. Description: Describe at a high level what the bug is. What happens? Why is it a bug? Not all bugs are obvious, so convince readers that it's actually a bug.

   • 2c) Log output: Paste terminal output and/or complete logs in a code block. DO NOT REDACT INFORMATION except for credentials. Please enable debug and access logs.
   • 2d) Workaround: What are you doing to work around the problem in the meantime? This can help others who encounter the same problem, until we implement a fix.
   • 2e) Relevant links: Please link to any related issues, pull requests, docs, and/or discussion. This can add crucial context to your report.

3. Tutorial: What are the minimum required specific steps someone needs to take in order to experience the same bug? Your goal here is to make sure that anyone else can have the same experience with the bug as you do. You are writing a tutorial, so make sure to carry it out yourself before posting it. Please:

   • Start with an empty config. Add only the lines/parameters that are absolutely required to reproduce the bug.
   • Do not run Caddy inside containers.
   • Run Caddy manually in your terminal; do not use systemd or other init systems.
   • If making HTTP requests, avoid web browsers. Use a simpler HTTP client instead, like curl.
   • Do not redact any information from your config (except credentials). Domain names are public knowledge and often necessary for quick resolution of an issue!
   • Note that ignoring this advice may result in delays, or even in your issue being closed. 😞 Only actionable issues are kept open, and if there is not enough information or clarity to reproduce the bug, then the report is not actionable.

Example of a tutorial:

Create a config file: ``` { ... } ``` Open terminal and run Caddy: ``` $ caddy ... ``` Make an HTTP request: ``` $ curl ... ``` Notice that the result is ___ but it should be ___.