NoBaxx · Case studySince 03/2026

Azure target architecture for a multi-tenant SaaS platform

Target architecture for antibaxx360, a multi-tenant SaaS ERP on Azure: Container Apps, database-enforced tenant isolation, and deep Microsoft integration from Entra ID to Graph.

86
Tenant-isolated tables under RLS: 44
Domain modules in the NestJS monolith: 22
Architecture decision records: 12
BullMQ queues in the worker

antibaxx360 target architecture on Azure, simplified excerpt

Role

Lead Software Engineer: end-to-end ownership of the solution architecture, engineering standards, and leadership of a team of five developers.

Context

NoBaxx runs antibaxx360, a SaaS ERP for pest control designed to support roughly 10,000 customers and about 8,000 business locations. The platform currently runs as a dev and beta environment on Hetzner and was built from day one, by explicit architecture decision, for production on Azure Container Apps.

The task

The task: derive a solid Azure target architecture from 22 architecture decision records and the real codebase, carrying business-critical operations, dependable field work, and audit-proof documentation on a platform whose tenant isolation is enforced by the database itself.

Constraints

Tenant isolation must be enforced by the database: row-level security with FORCE policies on 86 tables, protected by a dedicated CI gate
Chromium PDF rendering in the worker needs its own scaling and memory model (2 to 4 GB RAM)
EU data residency and GDPR deletion paths for HACCP- and IFS-audited customers
A small team of five developers: managed services over self-managed infrastructure, migration as configuration rather than rework

Architectural approach

One ingress, two compute workloads, three managed data services: Azure Front Door Premium with WAF at the edge, three React SPAs served from Static Web Apps, the NestJS monolith and the BullMQ worker as Container Apps inside a VNet, backed by Azure Database for PostgreSQL (Flexible Server, zone-redundant HA), Azure Cache for Redis, and Blob Storage with Defender malware scanning, reachable only through private endpoints.

Scaling follows the work: the API scales on HTTP concurrency, the worker scales through KEDA on Redis queue length, and PDF rendering gets its own memory profile. A migrate job (Prisma plus RLS SQL) runs as a gate before every new revision.

Security in seven layers: WAF and rate limits at the edge, JWT and OIDC SSO, row-level security as the primary tenant isolation, application-layer cryptography, a tamper-evident audit log with a hash chain, private endpoints on the network, and EU data residency in Germany West Central.

Deep in the Microsoft platform: Entra ID for OAuth and customer SSO, a productive two-way Outlook sync via Microsoft Graph, Exchange Online for the CRM inbox, Key Vault and Managed Identity for secrets, Application Insights for observability. Deployment runs through GitHub Actions into the Container Registry, provisioned with infrastructure as code.

Key decisions

A modular monolith instead of a microservice zoo

44 domain modules in one NestJS monolith with four cleanly separated API surfaces: one deployment, clear boundaries, right-sized for the team (ADR-001).

The database enforces tenant isolation

PostgreSQL row-level security with FORCE policies on 86 tables, a runtime user without bypass rights, and a CI gate that blocks any unprotected table: isolation is enforced, not a convention.

Scale on work, not on traffic

KEDA scales the worker on Redis queue length, independently of the API; exactly the model Chromium PDF rendering needs with its memory profile (ADR-006).

Cloud portability from day one

Identical container images for dev and production and a pluggable storage interface with a finished Azure Blob provider: the move to Azure is configuration, not rework (ADR-009, ADR-022).

Azure, because the product already speaks Microsoft

The Outlook calendar sync via Microsoft Graph runs in production, customer identities often live in Entra ID, and the EU region opens doors with audited customers: hosting, identity, and integration converge on one platform.

Technologies & focus

Azure: Front Door Premium + WAF, Static Web Apps, Container Apps + KEDA, Container Apps Jobs, PostgreSQL Flexible Server, Azure Cache for Redis, Blob Storage + Defender, Key Vault, Managed Identity, Application Insights, VNet + private endpoints, Container Registry, Azure DNS
Microsoft integration: Microsoft Entra ID (OAuth, SSO), Microsoft Graph (Outlook sync), Exchange Online, Azure Communication Services (email)
Engineering: NestJS, React, Flutter, PostgreSQL + PostGIS, Row-level security, Prisma, BullMQ + Redis, GitHub Actions, Bicep/Terraform

Status & outcome

Ongoing since 03/2026. The Azure target architecture is derived from 22 ADRs and the actual codebase; the migration path from the Hetzner dev environment to Azure is defined in seven steps, including an honest list of gaps to close before go-live.