the-biergarten-app/docs/web/diagrams/deployment.md

Docker Deployment Architecture

--8<-- "web/diagrams/deployment.mmd"

Notes

Environment	Details
Dev network (devnet, bridge)	Internal DNS resolves service names such as sqlserver and api.core. Volumes: sqlserverdata-dev, nuget-cache-dev, seaweedfsdata-dev. Startup order: SQL Server (health check) → migrations (run-once) → seed (run-once, depends on seaweedfs) → API (long-running, depends on seed).
Test network (testnet, bridge)	All test components are isolated; fresh DB instance each run (CLEAR_DATABASE=true, ephemeral sqlserverdata-test / seaweedfsdata-test volumes). api.specs, unit.tests, and frontend.tests all run as separate containers; results are aggregated.
Prod network (prodnet, bridge)	Isolated from dev/test networks. Volumes: sqlserverdata-prod, nuget-cache-prod. No seed step in production.
Database-only environment	Same devnet volumes/images as docker-compose.dev.yaml, minus api.core, frontend, and mailpit — for working against the database (and object storage, since seaweedfs is still included) without running the API or website.
Minimal environment	Database + migrations + seed + seaweedfs + mailpit, no API or frontend container — for frontend development against an API.Core process run outside Docker.
unit.tests	Builds Dockerfile.tests, which restores/builds against Biergarten.API.slnx and then runs dotnet test for every Features/*.Tests project in turn (Features.Users.Tests, Features.Breweries.Tests, Features.Emails.Tests, Features.PhotoUpload.Tests), mocking each handler's repository/service dependencies with Moq — no real database needed.
.trx results	Readable by Visual Studio, Azure DevOps, and GitHub Actions.