Migration/docker postgres

[TVW96]

Summary & Changes 📃

• Resolves: Containerize Application with Docker #158

Summary

Integrates containerization standards, utilizing Docker CLI and Docker Desktop GUI. The added code changes have successfully reduced the overall occurrences of configuration drift, and deduplicated values across the tech-stack. By defining each component as an isolated containerized image, the entire project environment becomes standardized, including configuration mappings for service ↔ database credentials, reverse proxy ↔ service containers, and route prefixes ↔ backend API handlers.

This modular setup allows each service to be independently developed, tested, and maintained. By composing these services through Traefik’s reverse proxy, we ensure seamless routing and integration. As a result, the entire environment is production-ready, with consistent behavior across testing, development, and deployment stages.

Changes Made

• Added: Traefik, Postgres, and PgAdmin services.
• Added: Centralized .env file at the application root containing database variables shared across the tech stack.
• Added: Service containers running Postgres, Next.js, NestJS, Traefik, and PgAdmin images.
• Removed: Database compose and build process from the E2E testing workflow. The tests now use a Postgres Docker container image instead.
• Consolidated: Frontend and backend traffic to a single port. The application now runs entirely on http://localhost (port 80).

Note

This configuration reflects the preferred production-style architecture, where services are containerized and routed through a reverse proxy.

What is the expected behavior?

With Docker Desktop open, we should be able to build the entire application with only 2 commands, accessing the website at:

• http://localhost/ → Next.js frontend
• http://localhost/api → NestJS backend
• http://localhost:8080 → Traefik dashboard

How to Test 🧪

1. In your root directory run the setup script

linux:

setup-macos-linux.sh 

windows:

setup-windows.bat

2. Open Docker Desktop GUI & build the app container by running this command in your root directory:

npm run docker

[beimnettes]

I checked this branch locally and reviewed the changes.

The Docker setup and project structure look correct, and the application starts until required environment variables (such as JWT_SECRET) are needed. Those errors are expected locally and match the PR notes.

However, the CI checks are still failing and the branch is out of date with main. These issues should be resolved before merge.

[github-actions]

✅ Full E2E Test Results

Running full test suite (critical files changed)

Status	Count
✅ Passed	43
❌ Failed	0
📊 Total	43

View detailed report

[TVW96]

@NahomAlemu @beimnettes

Docker compose builds frontend, backend, and postgres. I removed these build steps from playwright and changed the playwright_api_url to match the traefik (reverse proxy) route.

I also removed the hardcoded environment configurations from playwright and github workflows, leaving a shared set of values in root to be accessed across backend, testing, and development environments. Now when app is started using Docker Compose these values are inherited.

This is similar to the previous setup but does not use the --workspace prefix(not read across containers) and requires less hardcoded values. Since values can be pulled from the shell used to compose the application.

  // Start Docker Compose services if not already running,
  // services are accessible at http://localhost (port 80) via Traefik proxy
  webServer: {
    command: "docker compose up -d && tail -f /dev/null",
    url: "http://localhost",
    reuseExistingServer: true, // Don't restart if services are already running
    timeout: 240000,
  },

Before using Docker Compose:

1. Separate postgres databases. One for local(127.0.0.1:port/api) and another for workflows(localhost:port/api).
2. Deduplicated project dependencies. (consistent package-lock.json updates required).
3. Bifurcated port values. Separate url & api port locations creating CORS-policy error.
4. Propagating environment variables. ...

The compose.yml file at root provides fallbacks for all values not found in the smoke and e2e testing when application is ran in test mode NODE_ENV: test. *Read the compose.yaml file to learn more about the project workflow. Checkout the Dockerfile to learn more on the build process.

[NahomAlemu]

Well done! I was able to successfully spin up the entire stack and verify the containerization strategy on my local machine.

Testing Highlights

• Unified Routing: Confirmed Traefik correctly handles traffic at http://localhost (Frontend) and http://localhost/api (Backend/Swagger) and e2e testing.
• Functional Flow: Successfully created a new user via Swagger and verified the login flow on the frontend - database persistence is solid.
• Verified Hot Reload is working for both services by updating a code.

I noticed package-lock.json updated due to an npm version mismatch between my host and the container. This is fine for now, but we should standardize the npm version in the Dockerfile to avoid git noise.

[github-actions]

✅ Full E2E Test Results

Running full test suite (critical files changed)

Status	Count
✅ Passed	16
❌ Failed	0
📊 Total	16

View detailed report

[beimnettes]

I reviewed this branch locally and checked the Docker setup.

The container configuration looks correct and the services start properly using Docker Compose. The routing through http://localhost and /api works as expected with Traefik.

I also saw that the E2E tests are passing, which shows the container environment works with the testing setup.

Overall this change improves the project by making the development environment more consistent and easier to run.

[github-actions]

✅ Full E2E Test Results

Running full test suite (critical files changed)

Status	Count
✅ Passed	43
❌ Failed	0
📊 Total	43

View detailed report