davidherran
ba002ea9e6
Deploy to VPS / deploy (push) Has been cancelled
THREE FIXES IN ONE SHOT. 1. UPLOAD EACCES (the crashing one) The /app/public/branding upload was failing with EACCES because the folder on the host was created by `debian` (uid 1000) but the container runs as nextjs (uid 1001). Docker bind mounts preserve host ownership, so the container couldn't write into branding/. Fix: introduce a docker-entrypoint.sh that runs the container briefly as root, chowns every public/* mount to uid 1001, runs Prisma migrate deploy, then drops to nextjs via `su-exec`. From now on every deploy self-heals permissions across all asset folders (branding, footage, applications, cases, news, parts, operations-inbox) — even if a future volume gets added with the wrong owner. Dockerfile changes: - Adds `su-exec` package (lightweight gosu equivalent for Alpine) - Removes the static USER directive (entrypoint manages user transitions) - Replaces CMD with an ENTRYPOINT pointing at the new script 2. metadataBase WARNING Server logs were emitting: ⚠ metadataBase property in metadata export is not set ... using "http://localhost:3000" That's the layout's generateMetadata not declaring metadataBase, so Next.js couldn't resolve relative OG/Twitter image URLs to absolute ones. Reading NEXT_PUBLIC_APP_URL (already set in docker-compose env) and feeding it as `metadataBase: new URL(...)` silences the warning and produces correct absolute URLs in social previews. 3. PERMISSIONS DOCS The entrypoint chown is idempotent and silent on non-existent folders, so future volumes added to docker-compose just work. No more "did you sudo chown the new folder" gotchas. DEPLOY (David) cd /opt/flux-srl # one-time fix for the existing branding folder so the next deploy # doesn't have to chown 65MB of data — but the entrypoint now handles # this automatically anyway: sudo chown -R 1001:1001 /opt/flux-srl/public/branding git pull docker compose up -d --build app