prod-swarm-deploy

Build and push images with a new version tag, update the tags in docker-stack.yml with sed, then run docker stack deploy with --with-registry-auth so swarm nodes can pull from Docker Hub. Wait for convergence by polling docker stack ps until no tasks remain in Starting or Pending states.

Use a gated entrypoint flag instead of running prisma db push directly: set DB_AUTO_PUSH=true on the service with docker service update, confirm the push in logs, then flip it back to false. This avoids permission-blocked --accept-data-loss commands against production.

This usually means the API returned a 500 or the Next.js proxy cannot reach the API. Check API logs first; if it is a proxy issue, INTERNAL_API_URL was not baked at build time, so rebuild the web image with --build-arg INTERNAL_API_URL set to the API host.

Swarm workers cache image digests, so pushing to the same tag may not trigger a real pull. Always bump the version tag on every push and update the stack file to reference the new tag before redeploying.

The default start-first update order conflicts with mode: host ports because the new task cannot bind a port the old task still holds. Use stop-first ordering, or force it with docker service update --update-order stop-first --force on the service.