Next.js rewrites are evaluated at build time, not runtime.
The API_INTERNAL_URL was set in K8s deployment but not during
the Docker build, causing fallback to localhost:5001.
- Added ENV API_INTERNAL_URL=http://workclub-api:8080
- This ensures Next.js rewrites point to internal K8s service
The deployment was unreachable because the Next.js server was binding
to localhost:3000 (127.0.0.1) instead of 0.0.0.0, making it only
accessible inside the Docker container.
- Added HOSTNAME=0.0.0.0 to Dockerfile build and runtime stages
- Added HOSTNAME=0.0.0.0 to docker-compose.yml for nextjs service
This allows the server to accept connections from external hosts.
Implements Tasks 23 & 24: Backend and Frontend Dockerfiles
Backend Dockerfiles:
- Dockerfile.dev: Development with dotnet watch hot reload
- Base: sdk:10.0, installs dotnet-ef tool
- Layer caching: csproj files copied before source
- Entry: dotnet watch run with --no-restore
- Dockerfile: Production multi-stage build
- Build stage: sdk:10.0, restore + build + publish
- Runtime stage: aspnet:10.0-alpine (~110MB)
- Health check: /health/live endpoint
- Non-root: USER app (built-in)
Frontend Dockerfiles:
- Dockerfile.dev: Development with Bun hot reload
- Base: node:22-alpine, installs Bun globally
- Layer caching: package.json + bun.lock before source
- Command: bun run dev
- Dockerfile: Production standalone 3-stage build
- Deps stage: Install with --frozen-lockfile
- Build stage: bun run build → standalone output
- Runner stage: node:22-alpine with non-root nextjs user
- Copies: .next/standalone, .next/static, public
- Health check: Node.js HTTP GET to port 3000
- Entry: node server.js (~240MB)
All Dockerfiles use layer caching optimization and security best practices.
Note: Docker build verification skipped (Docker daemon not running).
WorkClub Automation