How to deploy with Docker

svs build writes a production build without any config baked in. The same image then runs in every environment, configured only through env vars.

svs build --docker   # dist/ + a multi-stage Dockerfile and .dockerignore
docker build -t my-app .
docker run --rm -p 3333:3333 \
  -e APP_ENV=production -e APP_KEY=base64:… \
  -e DB_CONNECTION=mysql -e DATABASE_URL=mysql://app:secret@db:3306/app \
  my-app

• Non-root. The image runs as the node user, never root. .env* files are excluded from the build context.
• Registry. @samveys/* installs from the public Samveys registry with no token. If the registry is ever made private, pass a Gitea token with package Read as a build secret, docker build --secret id=SAMVEYS_NPM_TOKEN …: it reaches only the install step and is in no layer or the final image.
• Checks before traffic. Run svs check --deploy in the release step. It fails when APP_KEY is missing, when debug is on in production, or when a database connection does not answer.
• Health. Point the platform at /health/live (liveness) and /health/ready (readiness) from @samveys/health.
• Graceful shutdown. On SIGTERM, /health/ready turns 503 at once, so the load balancer stops sending traffic. New connections are refused, and in-flight requests finish within the shutdown timeout (default 10 s, inside Kubernetes' 30 s grace period). Then plugins shut down and connections close. Keep terminationGracePeriodSeconds above the app's shutdown timeout.
• Migrations. Run svs migrate --force as a one-off job before the new version takes traffic. Never run them from every replica on start. On PostgreSQL, unsafe operations are blocked.

The deployment target itself (Kubernetes, plain containers, or VMs) is still open. Nothing above depends on that choice.