How it is built

You do not need to know the internals to use IntegraCI, but understanding the shape helps when you reason about isolation, governance, and self-hosting. The platform is a small set of foundations, each with one job.

The foundations

• Database-enforced isolation. Tenant separation is enforced by row-level security in the database itself, not by application code remembering to filter. A request without tenant context sees nothing.
• A policy engine. Rules live as policy as code and are evaluated at pipeline gates and on platform actions. Every decision is logged and replayable.
• Durable workflows. Long-running work such as onboarding, deploys, and remediations runs as durable, resumable workflows, so a step that fails can retry without losing the thread.
• A dedicated secrets store. Connector and service credentials are sealed here, scoped and short-lived where possible, never written to logs or config.
• A governed AI gateway. Every model call routes through one place where policy applies, write actions pause for approval, and usage is recorded.
• A developer portal. The catalog, golden paths, and docs surface use familiar, extensible patterns, so what you see fits how your engineers already work rather than locking you in.
• Kubernetes and GitOps. Deploys are native on Kubernetes and reconcile through GitOps, so desired state is version-controlled and reversible.
• A tamper-evident audit trail. Platform actions are appended to a write-once trail that you can export as evidence.

Why it is built this way

Each choice pushes a guarantee down to where it cannot be bypassed. Isolation in the database holds even when a query forgets to filter. Policy as code means a control is a tested artifact, not a wiki page. The result is that governance is a property of the platform, not a process bolted on top.

For the same picture from the product side, see the marketing architecture overview.