Skip to content
New: see your fit and get a tailored quote in minutes.Try the estimator
Menu

How it is built

Foundations you already know, nothing invented.

A platform that gates your deploys and holds your tenant boundary is one you should be able to run yourself and verify. IntegraCI is built on foundations you already know: database row-level security, policy-as-code, durable workflows, a developer portal, Kubernetes and GitOps, a governed AI gateway, and a tamper-evident audit trail. You self-host it inside your own boundary and check that it does what we say, through an audit trail that proves itself.

The foundations

The foundations underneath, and what each does.

No invented components. Here is what IntegraCI is built on and what each part does, wired together so the controls are real and the boundary is enforced. You self-host it inside your own boundary and run it on your own terms.

  • Database-enforced row-level security

    Tenant isolation is enforced in the database with row-level security in FORCE mode. One tenant cannot read another's data, and the boundary holds even when application code has a bug.

  • Policy-as-code

    Your rules live as policy-as-code. The gate runs on every deploy, so the control that decides what ships is the same control you can read and test.

  • Durable workflows

    Long-running work runs as durable, recoverable workflows. A step that fails picks up where it left off instead of leaving you with a half-finished change.

  • Open developer portal

    The developer portal uses familiar, extensible patterns, so your catalog, golden paths, and plugins fit how your engineers already work.

  • Kubernetes and GitOps

    Delivery is GitOps on Kubernetes. VM, serverless, and static targets are handled through deploy workers, so the same flow reaches more than one kind of target.

  • Governed AI gateway

    AI runs behind a single governed gateway. Every AI action passes policy, waits for a human approval, and lands in the audit trail. There is no path around the controls.

  • Tamper-evident audit trail

    Every action is written once to a hash-chained trail. Each entry is cryptographically chained to the one before it, so a quiet edit breaks the chain and shows.

  • Connectors to the tools you run

    IntegraCI orchestrates and governs the CI, security, cloud, and observability tools you already run. It records and acts on their results rather than replacing them.

Why it is built this way

The design choices that make the guarantees hold.

Each foundation is here for a reason you can check. Isolation goes in the database so a code bug cannot leak data. Policy is code so you can read and test it. Workflows are durable so failures recover. AI is governed so it works under the same rules as everyone else.

  • Isolation lives in the database, not the app

    App-layer filtering is a rule you have to trust on every query. Row-level security in FORCE mode makes the database refuse the read, so the boundary holds even when a query forgets to filter.

  • Policy is code you can read and test

    Rules written as policy-as-code are versioned, readable, and run on every deploy. You stop tracking controls in a spreadsheet and start running them, with the same policy applying different thresholds per environment.

  • Workflows are durable, so failures are recoverable

    The workflow engine records each step. When something fails mid-flight, the workflow resumes from where it stopped instead of leaving a tenant or a deploy in an unknown state.

  • AI is governed, with a human in the loop

    Agents reach your tools only through the gateway. Every action passes policy, waits for an approval, and is recorded, so AI works under the same rules as everyone else.

Request path governed
  • policy.eval evaluated pass
  • db.rls tenant-scoped forced
  • workflow.run checkpointed durable
  • audit.append #a1f3… chained

every layer leaves a record

Run it yourself your boundary
  • deploy.target self-host to air-gap yours
  • deploy.helm your cluster ready
  • data.residency stays with you yours
  • audit.trail hash-chained verify

run it, then verify every action

Run it, verify it

You self-host it, and verify it.

You do not have to take the architecture on faith. Stand it up on your own cluster, keep your data where you want it, and verify every action through a tamper-evident audit trail. The same platform runs from a guided evaluation to a self-hosted install behind your own perimeter.

See the foundations, then build on them.

Request a demo and see the gates, the durable workflows, and the database-enforced boundary working. When you are ready, run the same platform on your own cluster, inside your own boundary.