sirily
1a7250467e
## Summary - harden the web runtime with JSON body limits, stricter generation input validation, rate limiting, and trusted Origin/Referer checks for cookie-authenticated mutations - redact password-reset tokens from debug email transport logs and fail closed for unsupported email providers - scope generation idempotency keys per user with a Prisma migration and regression coverage ## Testing - docker build -f infra/docker/web.Dockerfile -t nroxy-web-check . - docker run --rm --entrypoint sh nroxy-web-check -lc "pnpm --filter @nproxy/providers test && pnpm --filter @nproxy/db test && pnpm --filter @nproxy/web test" Closes #14 Closes #7 Closes #8 Co-authored-by: sirily <sirily@git.shararam.party> Reviewed-on: #21
51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
# Deployment Plan
|
|
|
|
## Chosen target
|
|
Deploy on one VPS with Docker Compose.
|
|
|
|
## Why this target
|
|
- The system has multiple long-lived components: web, worker, bot, database, and reverse proxy.
|
|
- Compose gives predictable service boundaries, easier upgrades, and easier recovery than manually managed host processes.
|
|
- It preserves clear service boundaries if separation is ever needed later.
|
|
|
|
## Expected services
|
|
- `migrate`: one-shot schema bootstrap job run before app services start
|
|
- `web`: Next.js app serving the site, dashboard, admin UI, and API routes
|
|
- `worker`: background job processor
|
|
- `bot`: Telegram admin bot runtime
|
|
- `postgres`: primary database
|
|
- `caddy`: TLS termination and reverse proxy
|
|
- optional `minio`: self-hosted object storage for single-server deployments
|
|
|
|
## Deployment notes
|
|
- Run one Compose project on a single server.
|
|
- Keep persistent data in named volumes or external storage.
|
|
- Keep secrets in server-side environment files or a secret manager.
|
|
- Back up PostgreSQL and object storage separately.
|
|
- Prefer Telegram long polling to avoid an extra public webhook surface for the bot.
|
|
- In non-production environments, set `EMAIL_PROVIDER=example` only when you explicitly want the built-in debug transport. It logs redacted email previews and must never emit live password-reset tokens.
|
|
- Do not rely on implicit email fallbacks. Unsupported providers now fail fast at startup so misconfigured deployments do not silently drop password-reset or billing mail.
|
|
|
|
## Upgrade strategy
|
|
- Build new images.
|
|
- Run the one-shot database schema job.
|
|
- Restart `web`, `worker`, and `bot` in the same Compose project.
|
|
- Roll back by redeploying the previous image set if schema changes are backward compatible.
|
|
|
|
## Current database bootstrap state
|
|
- The current Compose template runs a `migrate` service before `web`, `worker`, and `bot`.
|
|
- The job runs `prisma migrate deploy` from the committed migration history.
|
|
- The same bootstrap job also ensures the default `SubscriptionPlan` row exists after migrations.
|
|
- Schema changes must land with a new committed Prisma migration before deployment.
|
|
|
|
## Initial operational checklist
|
|
- provision VPS
|
|
- install Docker and Compose plugin
|
|
- provision DNS and TLS
|
|
- provision PostgreSQL storage
|
|
- provision S3-compatible storage or enable local MinIO
|
|
- create `.env`
|
|
- deploy Compose stack
|
|
- run database migration job
|
|
- verify web health, worker job loop, and bot polling
|