Deployment architecture overview

MobilityManager ships as a single deployable unit: the .NET 10 API service hosts both the REST API and the compiled Angular 19 user interface. Understanding this model helps you plan hosting, scaling, and reverse-proxy configuration correctly.

One process serves both API and UI

During a Release build, the Angular application in src/web/UI is compiled and copied into the API project's wwwroot folder. At runtime, one Kestrel process serves everything from a single port (8080 in containers):

• API routes (for example /api/..., /healthz) are matched first.
• Static assets (JavaScript, CSS, images) are served from wwwroot.
• Unmatched routes fall back to index.html, so Angular client-side routing works on deep links and page refreshes.

Note: Because the UI and API share an origin, you do not need to configure CORS between them in a standard deployment. There is no separate web server to run or scale.

How the bundle is produced

The build behaviour depends on configuration:

• Development builds do not build the Angular UI, keeping compile times fast.
• Release builds automatically build and bundle the UI.
• You can force a UI build in any configuration with /p:BuildAngularUI=true.

To produce a deployable output, publish only the API project:

dotnet publish src/CK.MobilityManager.ApiService -c Release -o ./publish

The published folder contains the .NET binaries and the Angular assets in wwwroot, ready to run behind a reverse proxy or inside a container.

Multi-tenant data layer

The application separates data into two databases, addressed by named connection strings:

• SystemConnection — the system database holding the tenant registry, users, roles, and license.
• TenantConnection — the tenant database holding fleet, booking, and operational data.

Both PostgreSQL and Microsoft SQL Server are supported through the DatabaseProvider setting. Roles are fixed at three levels: SystemAdmin, FleetManager, and Driver.

Deployment options

You can run the single deployment in several ways, all covered by dedicated articles:

• Docker Compose for local evaluation and small deployments.
• A prebuilt container image for production Compose stacks.
• Kubernetes using the provided Kustomize manifests.
• A published folder run directly with dotnet behind your own reverse proxy.

Tip: In every deployment mode the container or process listens on a single HTTP port. Terminate TLS at your reverse proxy, load balancer, or ingress and forward plain HTTP to the app.

Related

• Prerequisites for building and running the platform
• Running the platform with Docker Compose in production
• Kubernetes deployment overview
• Migrations and the onboarding redirect on startup