Architecture
IntegraHive is a multi-tenant B2B data-integration platform. Partners deliver data over REST, secure file transfer, or direct upload; the platform infers the schema, versions the contract, stages the records, applies governance rules, quarantines what breaks the contract, and raises anomaly events — with tenant isolation enforced by the database rather than by application code.
Shape of the system
The application is a Next.js App Router codebase in TypeScript. The public marketing surface is a separate static site; the platform itself is a single deployable serving the operator console, the partner portal, and the API.
It runs on Azure Container Apps behind external ingress, with HTTP-concurrency autoscaling and startup, liveness, and readiness probes against a health endpoint. Work is split across four workload types:
| Workload | Role |
|---|---|
| Web | Console, partner portal, API |
| Workers | Long-running queue consumers |
| ML service | Inference, profiling, anomaly detection |
| Jobs | One-shot tasks — migrations, probes, backfills |
Container images are built remotely by the registry's build service rather than on CI runners, so a build needs no Docker daemon and no privileged runner.
Data
Managed PostgreSQL on a private virtual network — no public database endpoint. Application connections carry no password in configuration: the connection string is non-secret and the credential is a separate reference resolved from a managed vault at runtime.
Tenant isolation is a row-level-security policy bound to a least-privilege runtime role. This is the load-bearing design decision and it has its own document.
Messaging
NATS carries the internal event spine, deployed as an internal-only container app with no public ingress. Producers and consumers address it on the cluster network; it is not reachable from outside the environment.
Identity and secrets
Console access is enterprise SSO over OIDC, with SAML supported for partners that require it. Server-to-server and partner traffic authenticate with scoped API keys instead of user sessions.
No credential is committed. Secrets live in a managed vault and are referenced by workload identity, so a running container acquires them from its own identity rather than from injected configuration. CI asserts this rather than trusting it: guard tests parse the infrastructure variable files and fail the build if a credentialed connection string, a plaintext client secret, or a versioned vault URI appears.
Delivery
Infrastructure is Terraform, split per layer with isolated remote state so one layer's failure cannot corrupt another's. CI authenticates to the cloud by OIDC federation — there are no long-lived cloud credentials in the CI provider — and applies are gated behind explicit approval rather than firing on merge.
The unusual part is how correctness is asserted. Rather than relying on plan review, unit tests parse the Terraform variable files directly and assert the wiring: that a password is never a plain environment variable, that no key appears in both the environment map and the secret map (which would emit duplicate entries), and that a development identifier never appears in production configuration. These guards fail closed — a missing or malformed value trips the suite rather than passing quietly.
Request-path security
Strict Content-Security-Policy, HSTS, and a versioned API that emits deprecation and sunset headers on unversioned routes. CSRF uses a double-submit cookie. The middleware strips client-supplied trusted partner-identity headers before they reach a handler, so a client cannot forge the identity that downstream code trusts.
What is deployed
A development environment is live and running the full stack. Staging and production are defined in code but not deployed. Published material says so plainly — see engineering notes for why that matters more than it might appear.