Files

T

History

Hartmut 78d50b78d3 fix: script portability and npm security updates

Scripts:
- stop.sh: replace Linux-only fuser with cross-platform lsof fallback
- start.sh: parameterize port (APP_PORT) and container name (dynamic lookup)
- app-dev-start.sh: cross-platform stat (GNU -c / BSD -f) and setpriv/su fallback
- deploy-compose.sh: parameterize Docker registry via DOCKER_REGISTRY env var
- harden-postgres.sh: make DB_USER and DB_NAME configurable via env vars

NPM security:
- next: 15.5.12 → 15.5.15 (fixes HTTP request smuggling CVE)
- nodemailer: 8.0.1 → 8.0.5 (fixes SMTP command injection CVEs)
- lodash-es: add pnpm override to force >=4.18.0 (fixes code injection + prototype pollution)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

2026-04-10 14:06:58 +02:00

.env.production.example

refactor(ops): standardize image-based production delivery

2026-03-30 23:35:29 +02:00

deploy-compose.sh

fix: script portability and npm security updates

2026-04-10 14:06:58 +02:00

deploy.env.example

refactor(ops): standardize image-based production delivery

2026-03-30 23:35:29 +02:00

README.md

refactor(ops): standardize image-based production delivery

2026-03-30 23:35:29 +02:00

README.md

Deploy Tooling

This directory contains the canonical host-side tooling for the image-based staging and production path.

Files

deploy-compose.sh: validates compose input, pulls images, runs migrations, starts the app, and waits for readiness
.env.production.example: example host-side runtime configuration
deploy.env.example: example short-lived deployment manifest written by GitHub Actions

Host Layout

On the target host, the deploy directory should contain:

<deploy-path>/
  docker-compose.prod.yml
  deploy.env
  .env.production
  tooling/deploy/deploy-compose.sh

deploy.env is ephemeral and written by GitHub Actions for one deployment. .env.production stays on the host and contains the long-lived runtime secrets and app configuration.

First Setup

Copy tooling/deploy/.env.production.example to the target host as .env.production.
Fill in the required secrets and URLs.
Keep RATE_LIMIT_BACKEND=redis so production uses the shared counter path intentionally.
Copy tooling/deploy/deploy.env.example to the host only if you want to dry-run the deploy script manually.
Replace the placeholder images in deploy.env.example with a real sha-<commit> tag and save it as deploy.env for a manual dry run.
Provision runtime AI/SMTP/anonymization secrets on the host through .env.production or the platform's secret facility.
Keep admin settings for status/verification only; do not use them to enter or rotate operational secrets.
After migration, use the admin cleanup action to remove any legacy database-stored runtime secrets.
Ensure Docker Engine and Docker Compose v2 are installed.
Ensure the target host can pull from ghcr.io.
A normal release no longer needs a Git checkout on the host. The host only needs the deploy bundle plus the two env files.
Merge to main, let release-image.yml publish the immutable images, then run the staging or production deploy workflow with the same image tag.

Manual Host Test

After the files are present on the host, the canonical flow can be tested manually:

set -a
. ./deploy.env
set +a
bash tooling/deploy/deploy-compose.sh staging