Technical overview
Tenant-aware .NET Backend Platform
Self-directed multi-tenant .NET backend platform
- .NET ·
- ASP.NET Core ·
- EF Core ·
- React ·
- TypeScript ·
- Docker
Quick overview
Built a tenant-aware ASP.NET Core backend prototype with PostgreSQL, EF Core, JWT refresh tokens, permission management, runtime configuration APIs, and a React admin UI. The project explored multi-tenant backend architecture, admin/runtime API separation, and config-driven runtime behavior.
Personal project. Source code or selected implementation details can be shared when appropriate.
Context, responsibility, outcome, and takeaway
Context
I built a tenant-aware .NET backend platform for a casino/game operator scenario. Each tenant represented an operator using the platform’s games, and the system separated admin responsibilities from runtime game-facing endpoints through different .NET projects inside the same solution.
My role
I implemented the tenant/operator model, tenant users, Admin API, Runtime API, PostgreSQL/EF Core persistence, JWT authentication with refresh token rotation, permission management, runtime configuration endpoints, spin validation flow, React admin UI, and Docker-based local setup.
Result
The project demonstrates tenant isolation, admin/runtime API separation, JWT refresh flow, permission management, EF Core persistence, Docker-based local infrastructure, and config-driven runtime behavior without presenting it as a finished production platform.
Takeaway
Tenant-aware platforms become easier to reason about when admin responsibilities, runtime endpoints, permissions, and configuration flow are separated clearly.
How the backend flow is meant to be read
01
Tenant setup
The platform starts from a tenant/operator model. Admin users, permissions, runtime access, and configuration are scoped around that tenant boundary.
02
Admin access
Admin users authenticate with JWT access tokens and refresh token rotation, then work through protected admin operations for users, roles, permissions, tenants, and configuration.
03
Configuration flow
Configuration is stored through EF Core and PostgreSQL so admin-side changes can become runtime-facing behavior without mixing admin concerns into runtime endpoints.
04
Runtime request
Runtime clients call separate API-key protected endpoints to fetch effective configuration and submit runtime actions without receiving admin-level capabilities.
05
Persistence
Entity relationships, migrations, and DbContext boundaries keep tenant users, roles, permissions, configuration, and runtime state explicit and testable.
06
Demo value
The project is not presented as production software; it is a technical walkthrough of tenant-aware backend design, API separation, auth, permissions, persistence, and local Docker setup.
Admin and runtime separation
Admin UI
React / TypeScript dashboard
Admin API
Auth, users, roles, game config
Runtime API
API-key protected runtime endpoints
Persistence
EF Core, migrations, SQL-backed data
Separate administrative operations from runtime-facing integrations
01
Admin UI
02
Admin API
03
Database
04
Runtime API
05
Runtime client
Visual proof
Anonymized proof panels
Structured interface-style panels that show the project shape without exposing real users, client data, or private code.
Admin UI
Tenant administration
acme-demo · Active · Runtime enabled
northwind-test · Active · 3 API keys
sandbox · Disabled · Config draft
Access model
Roles and permissions
Admin · users.manage · tenants.manage
Operator · config.read · reports.view
Runtime client · api.read · config.fetch
Runtime API
Runtime configuration
GET /runtime/config/{tenant}
API key required
{ status: "active", version: "draft-12" }
Expandable details for the technical story
Why I built it
I built this project to practice platform-style backend design outside client work: separated APIs, tenant-aware behavior, admin operations, runtime configuration, authentication, authorization, persistence, and frontend administration in one local development setup.
Admin vs runtime separation
The platform separates administrative operations from runtime-facing behavior. Admin APIs handle users, roles, permissions, tenants, and configuration, while runtime endpoints expose only the data and actions needed by integration-facing clients.
Tenant isolation
Tenant-aware behavior is handled through tenant identifiers and protected admin operations, with the goal of keeping configuration, users, permissions, and runtime behavior separated across tenants.
Future improvements
Next improvements would include stronger integration tests, clearer tenant-scoped query enforcement, API documentation examples, seed data for demo environments, and a small public demo showing the admin/runtime flow without exposing sensitive configuration.
Core responsibilities and engineering details
- Tenant/operator model with tenant users and protected admin operations
- Separate Admin API and Runtime API projects inside one solution-level monolithic architecture
- PostgreSQL persistence with EF Core DbContext and migrations
- JWT authentication with refresh token rotation for admin access
Additional technical details 5 more points
- Permission management for tenant, user, role, and configuration operations
- Runtime configuration endpoint for retrieving effective game configuration
- Spin endpoint with session/configuration validation and backend business rules
- React admin UI for tenant, user, role, permission, and configuration management
- Docker-based local development setup
Concrete topics this project supports
- Admin API vs Runtime API separation
- Tenant-aware data separation and protected admin operations
- JWT authentication with refresh token rotation
- API-key protected runtime endpoints
- Users, roles, dynamic permissions, and access management
- EF Core migrations, SQL-backed persistence, and Docker Compose local setup