deploy.sh's header still says production copies nothing to the server #135

Closed
opened 2026-08-21 01:45:38 +00:00 by claude-bot · 2 comments
Collaborator

The comment block at the top of deploy/deploy.sh says:

Nothing is copied to the server for production. podman-compose runs here and talks to the server's podman socket, so the compose file and deploy/.env stay on this machine — the secrets in .env reach the server only as container environment, and there is no server-side copy to drift.

An environment that sets SERVER_STATE_DIR is the deliberate exception, and the dev stack is the one that does.

Both halves are now false. deploy/.env.example sets SERVER_STATE_DIR=/home/podman/ponente, and deploy/README.md says so outright — "Both stacks now set SERVER_STATE_DIR, and that is a real trade" — because the workstation-free release needs something on the server able to recreate the containers unattended. Production therefore does keep a 0600 copy of its env file in the podman user's home.

This is the load-bearing kind of stale: somebody reading only the script would conclude production's secrets are never written to disk on the server, which is exactly the property the release-without-a-workstation change traded away on purpose. The reasoning is already written down correctly in deploy/README.md and docs/deployment.md; only the script's header disagrees.

Found while adding the backup timer (#132) — the same SERVER_STATE_DIR block is what installs it — and left alone there to keep that change to one subject.


Filed by Claude while working on #132 (run).

The comment block at the top of [`deploy/deploy.sh`](deploy/deploy.sh) says: > Nothing is copied to the server for production. podman-compose runs here and talks to the server's podman socket, so the compose file and deploy/.env stay on this machine — the secrets in .env reach the server only as container environment, and there is no server-side copy to drift. > > An environment that sets SERVER_STATE_DIR is the deliberate exception, **and the dev stack is the one that does.** Both halves are now false. `deploy/.env.example` sets `SERVER_STATE_DIR=/home/podman/ponente`, and `deploy/README.md` says so outright — *"Both stacks now set `SERVER_STATE_DIR`, and that is a real trade"* — because the workstation-free release needs something on the server able to recreate the containers unattended. Production therefore does keep a `0600` copy of its env file in the podman user's home. This is the load-bearing kind of stale: somebody reading only the script would conclude production's secrets are never written to disk on the server, which is exactly the property the release-without-a-workstation change traded away on purpose. The reasoning is already written down correctly in `deploy/README.md` and `docs/deployment.md`; only the script's header disagrees. Found while adding the backup timer (#132) — the same `SERVER_STATE_DIR` block is what installs it — and left alone there to keep that change to one subject. --- _Filed by Claude while working on #132 ([run](https://git.grandiras.net/Grandiras/claude-bot/actions/runs/345))._
Author
Collaborator

🤖 On it — follow along in the action run; the reply will link the full session transcript.

📜 Live transcript — updating every ~5 minutes while the task runs.

🤖 On it — follow along in [the action run](https://git.grandiras.net/Grandiras/claude-bot/actions/runs/356); the reply will link the full session transcript. <!-- claude-run:comment --> 📜 [Live transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/issue-135/run-356.md) — updating every ~5 minutes while the task runs.
Author
Collaborator

Pushed claude/issue-135.

What changed — comments only, no behaviour.

deploy/deploy.sh header: the two paragraphs claiming production copies nothing to the server and that the dev stack is the lone SERVER_STATE_DIR exception are replaced. The new text keeps the part that is still true (the deploy itself needs nothing on the far side — podman-compose runs on the workstation against the server's socket), then states plainly that both stacks set SERVER_STATE_DIR, that production's secrets therefore also sit in a 0600 file in the podman user's home, and why that reversal was made on purpose: a release without a workstation needs something on the server able to recreate the containers unattended, and that thing needs the values. It also notes the same copy is what lets the stack back itself up (#132's timer), says what unsetting it costs, and points at deploy/README.md for the longer version. The "re-copied on every deploy so the server's copy cannot fall behind the repo" reasoning is kept — it applies to every stack now, not just dev.

One thing beyond the issue's scope, fixed rather than filed: deploy/.env.dev.example carried the identical false claim in its SERVER_STATE_DIR comment — "Production leaves it unset, and then nothing is copied at all." Same sentence, same subject, one line; splitting it into its own issue would have left the wrong statement sitting next to the corrected one. It now says production sets it too and points at .env.example, which holds the full trade.

Verified: bash -n deploy/deploy.sh passes; ./deploy/deploy.sh --help still prints the intended block (it seds lines 2–11, above the edited region, and that output is unchanged); dotnet test Ponente.sln — 380 passed, 0 failed, including DocumentationTests.

No changelog entry: nothing here is visible to a member. No docs page needed updating — deploy/README.md and docs/deployment.md were already the correct versions this change copies from.


⏱ 1m 23s · 12 turns · tokens: 29.6k in / 4.5k out (+328.2k cache-read)
📜 Full session transcript
→ Opened PR: #136

Pushed `claude/issue-135`. **What changed** — comments only, no behaviour. `deploy/deploy.sh` header: the two paragraphs claiming production copies nothing to the server and that the dev stack is the lone `SERVER_STATE_DIR` exception are replaced. The new text keeps the part that is still true (the deploy itself needs nothing on the far side — podman-compose runs on the workstation against the server's socket), then states plainly that both stacks set `SERVER_STATE_DIR`, that production's secrets therefore also sit in a `0600` file in the podman user's home, and why that reversal was made on purpose: a release without a workstation needs something on the server able to recreate the containers unattended, and that thing needs the values. It also notes the same copy is what lets the stack back itself up (#132's timer), says what unsetting it costs, and points at `deploy/README.md` for the longer version. The "re-copied on every deploy so the server's copy cannot fall behind the repo" reasoning is kept — it applies to every stack now, not just dev. **One thing beyond the issue's scope, fixed rather than filed:** `deploy/.env.dev.example` carried the identical false claim in its `SERVER_STATE_DIR` comment — *"Production leaves it unset, and then nothing is copied at all."* Same sentence, same subject, one line; splitting it into its own issue would have left the wrong statement sitting next to the corrected one. It now says production sets it too and points at `.env.example`, which holds the full trade. **Verified:** `bash -n deploy/deploy.sh` passes; `./deploy/deploy.sh --help` still prints the intended block (it `sed`s lines 2–11, above the edited region, and that output is unchanged); `dotnet test Ponente.sln` — 380 passed, 0 failed, including `DocumentationTests`. No changelog entry: nothing here is visible to a member. No docs page needed updating — `deploy/README.md` and `docs/deployment.md` were already the correct versions this change copies from. --- ⏱ 1m 23s · 12 turns · tokens: 29.6k in / 4.5k out (+328.2k cache-read) 📜 [Full session transcript](https://git.grandiras.net/Grandiras/claude-bot/src/branch/claude-logs/transcripts/Grandiras/Ponente/issue-135/run-356.md) → Opened PR: https://git.grandiras.net/Grandiras/Ponente/pulls/136
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Grandiras/Ponente#135
No description provided.