# Deployment

> Building the production images, configuration through environment variables, and running the production stack.

## Production stack

A second Compose file, `docker-compose.prod.yml`, builds the API image and runs the production
topology. The API ships with a `Dockerfile`; the frontend builds to static assets served by your CDN
or a static host.

```sh
docker compose -f docker-compose.prod.yml up -d --build
```

## Configuration is environment variables

Configuration follows a simple rule: the values in `appsettings.json` are **development placeholders**,
and every secret or environment-specific value is overridden by an environment variable in production.
There is no Key Vault or Secrets Manager scaffolding to adopt; wire your platform's secret mechanism
to environment variables and you are done.

Typical overrides:

- `ConnectionStrings__Postgres`
- `ConnectionStrings__Redis`
- `RabbitMq__*`, `Storage__*` (MinIO/S3)
- `Cors__AllowedOrigins`
- OTLP exporter endpoint for your collector

## Database migrations

EF Core migrations are applied automatically on start in development. For production, run them as an
explicit step in your deploy pipeline so a rollout never races the schema:

```sh
dotnet ef database update \
  --project api/src/Slicekit.Core \
  --startup-project api/src/Slicekit.Api \
  --context AppDbContext
```

## Behind a reverse proxy

The API trusts forwarded headers, so terminate TLS at your proxy or load balancer and forward the
scheme and client address. This keeps secure-cookie flags, redirects and audited IP addresses
correct.

## CI

GitHub Actions builds, tests and lints both sides on every push. Use the same workflows as the gate
for your deploys: a green build is a deployable build.

## Adapting it

Slicekit does not prescribe a host. The images are standard, the configuration is environment
variables, and the observability exporters are OTLP, so point them at your infrastructure and ship.