Skip to content
Slicekit

Operations

Deployment

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

View .md
On this page

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.

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:

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.