Replace railway redeploy with railway up using a dynamically generated
proxy Dockerfile. The proxy pulls the pre-built image from GHCR using
the exact SHA256 digest, avoiding Railpack source builds while ensuring
deterministic deployments.
Changed deployment command from `railway up` to `railway redeploy` because
the Railway service is configured to use an external Docker image from GHCR,
not source code deployment. The `railway up` command was attempting to build
from source with Railpack, which failed since no source code was provided.
The `railway redeploy` command triggers Railway to pull the latest image
from ghcr.io/xevion/pac-man:latest and redeploy the service.
The deployment was failing because the workflow used incorrect syntax
with `uses: docker://` which caused Docker to misinterpret `up` as an
executable rather than an argument to the Railway CLI.
Split deployment into a separate job using `container:` at the job level,
allowing the Railway CLI to execute properly. This follows Railway's
official documentation for GitHub Actions integration.
- Remove frontend build steps from GitHub Actions workflow
- Add frontend-builder stage using oven/bun:1 in Dockerfile
- Build frontend inside Docker for better consistency and portability
- Copy built frontend from frontend-builder stage to runtime image
- Simplify CI/CD pipeline by consolidating build steps
This commit introduces a comprehensive deployment strategy that unifies the frontend and backend into a single Docker container served by the Rust backend, streamlining the deployment process and improving production architecture.
Key changes:
- Split CI/CD workflows: separated build.yaml (for CI/PR checks) and deploy.yaml (for production deployment)
- Implemented unified Docker deployment where the Axum server serves both API routes (under /api) and frontend static files
- Added GitHub Container Registry integration for Docker image distribution
- Updated Railway configuration to use the new healthcheck path (/api/health)
- Enhanced postgres.ts script with named volumes and constants for better container management
- Added API client utilities (web/lib/api.ts) and environment configuration (web/.env.example) for frontend-backend communication
- Configured Vite proxy for local development while supporting same-origin requests in production
- Updated Dockerfile to include frontend static files and proper environment variable handling
This architecture eliminates the need for separate deployments and CORS configuration, as the frontend and API are served from the same origin.
