update deployment docs

checkpoint.md

@@ -35,7 +35,7 @@
 12. Added deployment runbook:
     - `DEPLOYMENT.md`
 
-## Passenger Web Migration to Next.js (Latest)
+## Passenger Web Migration to Next.js
 
 13. Passenger web apps migrated from Vite/SPA to Next.js:
     - Updated `apps/edr-passenger-web/portal/next.config.js` and `apps/edr-passenger-web/backoffice/next.config.js`:
@@ -44,17 +44,27 @@
 14. Created dedicated Next.js Dockerfile:
     - `infrastructure/docker/Dockerfile.passenger-web`
     - Uses Node.js server (not nginx) for better Next.js support
-    - Builds with turbo, deploys with `.next/standalone` server
-    - Accepts build args: `APP_PACKAGE`, `APP_PATH`, `PORT`, `NEXT_PUBLIC_API_URL`
+    - Builds with turbo, runs `npx next start` in the final stage
+    - Accepts build args: `APP_PACKAGE`, `APP_PATH`, `NEXT_PUBLIC_API_URL`
 15. Updated docker-compose.yaml:
     - `passenger-portal` and `passenger-backoffice` now use `infrastructure/docker/Dockerfile.passenger-web`
-    - Port mappings changed from container:80 to container:5174/5184 (Next.js actual ports)
-    - Updated build args to match new Dockerfile
-    - Changed env var from `PASSENGER_VITE_API_URL` to `PASSENGER_NEXT_PUBLIC_API_URL`
-16. Updated DEPLOYMENT.md:
-    - Added "Passenger Web Docker Configuration" section
-    - Documented differences between freight-web (Vite+nginx) and passenger-web (Next.js+Node.js)
-    - Updated build env file example to use `PASSENGER_NEXT_PUBLIC_API_URL`
+    - Port mappings are fully dynamic: both host and container ports use `${PASSENGER_PORTAL_PORT}` / `${PASSENGER_BACKOFFICE_PORT}`, driven by `PORT` in the service env file
+    - `NEXT_PUBLIC_API_URL` build arg sourced directly from the service env file (no separate build env file needed)
+16. Updated DEPLOYMENT.md to reflect all of the above.
+
+## Port Mapping Fix (Latest)
+
+17. Fixed passenger web port mapping mismatch (`0.0.0.0:8003->5184/tcp`):
+    - Container port was hardcoded (`5174`/`5184`); host port came from `PORT` in the env file via the sync script
+    - Both sides of the mapping now use `${PASSENGER_PORTAL_PORT:-5174}` / `${PASSENGER_BACKOFFICE_PORT:-5184}`
+    - Removed hardcoded `PORT` build arg from docker-compose.yaml (runtime `env_file` supplies it to Next.js)
+
+## NEXT_PUBLIC_API_URL Build-Time Fix (Latest)
+
+18. Fixed passenger web apps using `localhost:4000` instead of the configured API URL:
+    - Root cause: `NEXT_PUBLIC_*` vars are baked into the JS bundle at build time; setting them in the runtime `env_file` has no effect
+    - `sync-env-from-server.sh` now extracts any `NEXT_PUBLIC_*` vars from the service `.env` and writes them to `GITHUB_ENV` before the build step
+    - `docker-compose.yaml` build arg renamed from `PASSENGER_NEXT_PUBLIC_API_URL` to `NEXT_PUBLIC_API_URL` to match the key used in the service env files directly
 
 ## Key Files to Review
 
@@ -84,9 +94,9 @@
 2. Prisma warns about `package.json#prisma` deprecation (Prisma 7 migration pending).
 3. Matrix parallelism increases runner load; ensure self-hosted runner capacity is sufficient.
 4. Port collisions are prevented by env-driven mapping, but bad env values can still cause runtime conflicts.
-5. Passenger web now uses Next.js server mode (not static export):
+5. Passenger web uses Next.js server mode (not static export):
    - Requires Node.js at runtime (previously could use pure static hosting)
-   - Deployment must ensure `PASSENGER_NEXT_PUBLIC_API_URL` is set in build env for production deployments
+   - `NEXT_PUBLIC_API_URL` must be set in the service env file (`passenger-portal.env` / `passenger-backoffice.env`) — the sync script forwards it to the build automatically
    - Each portal/backoffice instance runs its own Node.js process (watch container memory usage)
 6. Freight web still uses Vite+nginx (different from passenger web) — maintain both Dockerfiles separately