Deploy with a deploy key, a trial run and a full rollback

[andersgar]

Fetches main with a read-only deploy key instead of a token. The new image is tried on a copy of the database before the real container is replaced, and a rollback restores files, image and database. Adds /version, which the Deploy workflow uses to record each deploy on GitHub. Fixes the three review findings on #13.

[Copilot]

Copilot review overview

🟡 Changes recommended

Unresolved deployment safety, rollback, trial-isolation, host-key, and workflow timeout issues remain.

Review effort: Lite
Findings: 2 · 1

Open (3)

• Accepting unknown GitHub host keys enables repository interception · New
• Trial mode can send real mail through the production backend · New
• Initial sync leaves deleted repository files in the application directory · New

What changed in this PR

Adds deploy-key-based deployments with trial validation, rollback support, and GitHub deployment tracking through /version.

Changes:

• Adds /version and deployment metadata handling.
• Reworks deployment with database trials, health checks, and rollback.
• Updates deployment documentation and GitHub Actions monitoring.

File	Description
src/​server.ts	Adds /version.
README.md	Documents the endpoint.
docker-compose.yaml	Loads deployment metadata.
deploy/​README.md	Documents deployment setup and behavior.
deploy/​deploy.sh	Implements fetching, trials, deployment, and rollback.
deploy/​deploy.env.example	Defines deploy-key configuration.
.github/​workflows/​deploy.yml	Records and monitors deployments.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

Critical rollback and database-consistency issues remain, along with synchronization and workflow-timeout defects.

Review effort: Lite
Findings: 2 · 1

Open (3)

• Trial uses stale database backup and can lose writes · New
• Rollback restores database after failed container start · New
• Initial deployment leaves stale root-level files · New

Resolved since last review (3)

• Trial mode can send real mail through the production backend
• Accepting unknown GitHub host keys enables repository interception
• Initial sync leaves deleted repository files in the application directory

Previously missed (2)

In code that hasn't changed since last review

Polling loop can exceed job timeout

.github/​workflows/​deploy.yml:47

The polling loop can run for up to 45 × (10 seconds for curl --max-time + 20 seconds of sleep) = 1,350 seconds, which is 22.5 minutes. That exceeds the job's 20-minute timeout and contradicts the 15-minute failure message, so a slow/unreachable endpoint can cancel the job before this workflow reports a failure. Reduce the iteration bound or otherwise make the loop's worst-case duration fit both limits.

Cleanup deletes operator-owned empty directories

deploy/​deploy.sh:53

This cleanup scans all of APP_DIR, not just directories that belonged to the previous commit. It therefore deletes any empty operator-owned directory, despite the surrounding contract that files and directories the repository does not own stay untouched. Restrict the directory cleanup to parent directories of the files removed from the Git tree (or to repository-owned roots).