Add Docker and docker-compose configuration for local development and deployment

[Josie123-Dev]

What

Create a Dockerfile for the backend, a Dockerfile for the frontend, and a docker-compose.yml at the project root that orchestrates all services (backend, frontend, PostgreSQL, Redis) for local development.

Why

DEPLOYMENT.md and README.md both reference Docker, but no Dockerfile or docker-compose configuration exists. New contributors currently need to manually install PostgreSQL, Redis, Node.js, Rust, and Circom just to run the backend locally. A docker-compose setup reduces onboarding from hours to minutes and ensures consistent environments across contributors.

Scope

In scope:

• backend/Dockerfile — multi-stage build (build + production)
• frontend/Dockerfile — multi-stage build (build + production)
• docker-compose.yml at root — backend, frontend, postgres, redis services
• .dockerignore files for backend and frontend
• Environment variable configuration via .env file (reference .env.example)
• Health checks for all services in docker-compose

Out of scope:

• Kubernetes manifests
• CI/CD Docker image publishing
• Smart contract compilation in Docker (Rust/WASM toolchain is heavy; keep as local install)
• ZK circuit compilation in Docker

Acceptance Criteria

• docker-compose up starts all 4 services (backend, frontend, postgres, redis)
• Backend is accessible at http://localhost:3001/api/v1
• Frontend is accessible at http://localhost:3000
• PostgreSQL and Redis are accessible from the backend container
• docker-compose down -v cleanly tears down all services and volumes
• Dockerfiles use multi-stage builds for minimal production images
• .dockerignore excludes node_modules, .git, dist, target

Technical Context

• Backend: NestJS on port 3001 (see backend/src/main.ts)
• Frontend: Next.js on port 3000 (default)
• PostgreSQL: default port 5432, database name from .env.example
• Redis: default port 6379
• Backend .env.example has 71 lines of env vars — use these as the template
• Backend uses TypeORM with synchronize: true in dev — migrations not required for local dev

[Soldier224K]

Hi @Josie123-Dev, I’d like to take ownership of issue #162 and implement the Docker-based local development environment.

I can set up the complete Docker workflow while keeping the configuration aligned with the existing NestJS backend, Next.js frontend, and environment setup.

My approach will include:

• Creating a multi-stage backend/Dockerfile with separate build and production stages.
• Creating a multi-stage frontend/Dockerfile optimized for the Next.js production runtime.
• Adding a root-level docker-compose.yml orchestrating backend, frontend, PostgreSQL, and Redis.
• Adding appropriate .dockerignore files for both applications.
• Wiring environment variables through the existing .env.example structure without hardcoding secrets.
• Configuring service-to-service networking so the backend connects to PostgreSQL and Redis through Compose service names.
• Adding health checks and appropriate service dependencies.
• Verifying docker-compose up brings up all four services and that the expected endpoints are accessible.
• Verifying docker-compose down -v cleanly removes containers and development volumes.

I’ll keep the implementation focused on local development and deployment consistency, without introducing Kubernetes, CI/CD image publishing, or Dockerized Rust/WASM and Circom toolchains.

I’d be happy to take this issue and submit a clean PR with the Docker architecture, configuration decisions, and verification results documented.