## Docker Environments

Three Docker environments are available:

- `Dockerfile.dev` with `docker-compose.dev.yml`
- `Dockerfile.test` with `docker-compose.test.yml`
- `Dockerfile.production` with `docker-compose.production.yml`
- `docker-compose.pgmanage.yml` for a standalone pgManage container

### Development

Use the full dev stack for local work with hot reload and bundled Postgres and Redis:

```bash
docker compose -f docker-compose.dev.yml --profile full up --build
```

Services:

- marketplace: `http://localhost:3000`
- dashboard: `http://localhost:3001`
- admin: `http://localhost:3002`
- public-site: `http://localhost:3003`
- api: `http://localhost:4000`
- pgAdmin: `http://localhost:5050`

Each dev app now runs in its own container and can be started independently with a profile tag:

```bash
docker compose -f docker-compose.dev.yml --profile api up --build
docker compose -f docker-compose.dev.yml --profile marketplace up --build
docker compose -f docker-compose.dev.yml --profile dashboard up --build
docker compose -f docker-compose.dev.yml --profile admin up --build
docker compose -f docker-compose.dev.yml --profile public-site up --build
docker compose -f docker-compose.dev.yml --profile tools up --build
```

Notes:

- `api` starts `postgres`, `redis`, and `migrate` automatically through dependencies.
- frontend profiles also start `api` and its dependencies automatically.
- `tools` starts only `pgadmin` plus its required `postgres` dependency.

On startup, Docker now waits for Postgres to become healthy, runs a one-shot `migrate` service, and only then starts the selected app container. For development, that bootstrap runs `db:generate` every time, but `db:deploy` and `db:seed` only the first time for a persisted dev database, so your local data survives rebuilds and normal restarts.

Default dev platform administrator:

- email: `admin@rentaldrivego.com`
- password: `changeme123`

If you intentionally want a fresh dev bootstrap:

```bash
docker compose -f docker-compose.dev.yml down -v
```

If you want to keep the database and only apply new schema changes manually:

```bash
docker compose -f docker-compose.dev.yml run --rm migrate sh -c "npm run db:deploy"
```

pgAdmin dev login:

- email: `admin@rentaldrivego.local`
- email: `admin@rentaldrivego.dev`
- password: `admin`

pgAdmin opens with the dev Postgres server pre-registered as `RentalDriveGo Dev DB`.

pgAdmin Postgres connection:

- host: `postgres`
- port: `5432`
- database: `rentaldrivego`
- username: `postgres`
- password: `password`

### Standalone pgManage

If you want a standalone Postgres management UI without starting the full development stack:

```bash
docker compose -f docker-compose.pgmanage.yml up -d
```

It publishes `http://localhost:8000` with a standard Docker port mapping and persists its data in the named Docker volume `pgmanage_data`.
From inside the container, connect to the local Postgres service through `host.docker.internal:5432`.

### Test

Use the test stack to run repeatable containerized verification:

```bash
docker compose -f docker-compose.test.yml up --build --abort-on-container-exit
```

The test container runs:

- `npm run db:deploy`
- `npm run db:generate`
- `npm run type-check`
- `npm run build`

### Production

1. Copy `.env.docker.production.example` to `.env.docker.production`
2. Fill in real secrets and domain values
3. Start the stack:

```bash
docker compose -f docker-compose.production.yml up --build -d
```

Production compose starts separate containers for:

- postgres
- redis
- api
- marketplace
- dashboard
- admin
- public-site

### Notes

- The production image builds the whole monorepo once, then each service overrides its runtime command.
- The dev compose file bind-mounts the repo and keeps `node_modules` in a named volume.
- `API_INTERNAL_URL` is used for server-side container-to-container calls, while `NEXT_PUBLIC_API_URL` is used by the browser.
- The Dockerfiles activate the repo's pinned `npm@10.5.0` with `corepack` before install so container builds do not depend on the npm version bundled with the base image.
- The dev compose stack stores Postgres data in `postgres_dev_data` and the bootstrap marker in `postgres_bootstrap_state`, so `up --build` does not reseed an existing local database.
- If you need database schema updates inside Docker, run:

```bash
docker compose -f docker-compose.dev.yml run --rm migrate
```

If a cached base image still fails during `npm ci`, refresh it and rebuild without cache:

```bash
docker pull node:20-bookworm
docker compose -f docker-compose.dev.yml build --no-cache dashboard
```