Fix config file folder

README.md

@@ -179,15 +179,23 @@ recover individual five-minute values. Fully local operation leaves Wi-Fi gaps v
 ## Raspberry Pi service
 
 Deploy the checkout to `/var/www/html/solar-relay` and create/install its venv as above.
-Place configuration outside the web directory:
+The service reads **`/var/www/html/solar-relay/config.toml`**. Keep your existing local
+file there; deployment excludes it from both replacement and deletion. If this is a
+fresh installation, create it from the example only when it does not exist:
 
 ```bash
-sudo install -d -m 0755 /etc/solar-relay
-sudo install -m 0644 config.example.toml /etc/solar-relay/config.toml
-sudoedit /etc/solar-relay/config.toml
+cd /var/www/html/solar-relay
+test -e config.toml || cp config.example.toml config.toml
+chmod 0644 config.toml
 ```
 
-Use these collector settings, retaining the example's other sections:
+The dynamic service user needs read access to this configuration. It contains setting
+values and environment variable names; keep credentials in the root-readable environment
+file below. Ensure the proxy serves the status endpoint rather than repository files.
+
+For systemd, set the archive to its writable state directory in this local config,
+retaining your other settings. The relative development setting `data/archive` points
+inside the checkout, which the hardened service cannot write:
 
 ```toml
 [collector]
@@ -202,17 +210,21 @@ Set `[upload].url` to the main website's `https://your-solar-host/index.php?a=re
 Put `SOLAR_RELAY_TOKEN=your-shared-token` in `/etc/solar-relay/solar-relay.env` with
 permissions 0600, readable by root. Configure the same token and source ID on the
 main website as described in its README. Tokens and API keys stay out of TOML/Git.
+Create `/etc/solar-relay` with `sudo install -d -m 0755 /etc/solar-relay` when adding
+that optional environment file.
 
 ```bash
 sudo cp deploy/solar-relay.service /etc/systemd/system/
 sudo systemctl daemon-reload
-sudo systemctl enable --now solar-relay
-sudo journalctl -u solar-relay -f
+sudo systemctl enable solar-relay
 ```
 
 systemd provides `/var/lib/solar-relay` to a dynamic, unprivileged service user.
-Recording/uploading remains separate from serving status. Running tests or `sample`
-does not install/start the service. Initial systemd/configuration installation is manual.
+Recording/uploading remains separate from serving status. The first Gitea deployment
+installs the code/venv and starts the service through restart. After a manual installation,
+use `systemctl start solar-relay` when the code and venv are ready. Running
+tests or `sample` does not install/start the service. Initial unit installation is manual.
+Inspect service logs with `sudo journalctl -u solar-relay -f` after startup.
 
 ## HTTPS reverse proxy and status page
 
@@ -256,12 +268,13 @@ with **`solar-relay:host`**; its checkout must be separate from production.
 
 The runner needs Python 3.11+, `python3-venv`/pip, a supported 64-bit PyArrow platform,
 `rsync`, `flock`, `curl`, `sudo`, systemd and Node.js 20+ for `actions/checkout@v4`.
-Give its account write access to the deployment directory. Install the config and unit
-before the first deployment, then add a restricted sudoers rule using the actual runner
+The configured runner account is `www-data`. Give it write access to the deployment
+directory and keep the local config there. Install the unit before the first deployment,
+then add a restricted sudoers rule using the actual runner
 account and the path from `command -v systemctl`:
 
 ```sudoers
-gitea-runner ALL=(root) NOPASSWD: /usr/bin/systemctl restart solar-relay.service
+www-data ALL=(root) NOPASSWD: /usr/bin/systemctl restart solar-relay.service
 ```
 
 The workflow installs dependencies and runs tests in `.venv-ci`, checks the installed
@@ -269,7 +282,9 @@ unit, serializes deployment with `flock`, syncs source, installs runtime depende
 inside `.venv`, restarts and checks the service, then probes the public HTTPS health
 endpoint with certificate verification. Runtime venv/configuration, `data/` and
 Parquet files are preserved. Recommended state under `/var/lib` and
-configuration under `/etc` are entirely outside the sync and web directory.
+the credential environment file under `/etc` are outside the sync. The local
+`config.toml` is protected by the explicit rsync exclusion even when `--delete` is used.
+Deployment never copies `config.example.toml` over your configuration.
 
 If the deployment directory is initially empty, enable the unit without `--now`; the
 first deployment creates the venv and starts it. Set up the proxy before deployment.