Self-host
Some teams cannot send their pipeline, their secrets, or their compliance evidence to someone else's cloud. So run IntegraCI yourself. Deploy it with Helm to your own Kubernetes, air-gapped if you need it. The portal, the engine, governed AI, and the evidence you have to defend never leave your boundary. You run it on your own terms, on infrastructure you control.
Your own stack
Self-host means the full platform lives on infrastructure you own. You install it with Helm into a namespace on your Kubernetes cluster, and run it yourself inside your boundary instead of handing your pipeline and evidence to someone else's cloud.
The whole platform, your infrastructure
The portal, the engine, the connectors, and your compliance evidence run inside your boundary. Nothing has to leave it for the platform to work.
Deploy with Helm to Kubernetes
Install into a namespace on a cluster you already operate. The same Helm profiles power a small evaluation tenant and a production setup, so you scale the install, not the approach.
Runs inside your boundary
You self-host the platform on your own infrastructure, all the way to air-gapped, so the data and the governed AI never leave your control. Every action lands in a tamper-evident audit trail you can verify.
deployed to infrastructure you own
inside the edge
nothing leaves the boundary
Air-gapped
The platform needs no outbound dependency to run. Mirror the container images into your own OCI registry, verify their signatures, and pin them by digest, so what installs is exactly what you approved. Even governed AI can run against a model you host inside the edge.
No outbound dependency required
The platform does not phone home to function. Run it on a network with no path to the public internet and the engine, portal, and policy checks keep working.
Mirror images to your own registry
Pull the container images once, mirror them into the OCI registry inside your boundary, and install from there. Updates follow the same mirror, on your schedule.
Signature-verified, digest-pinned
Images can be signature-verified before they run and pinned by digest, so what installs is exactly what you mirrored. No surprise tag moves.
Governed AI inside your boundary
Point the model-agnostic LLM layer at a model you host. AI actions stay human-in-the-loop and the prompts and data never cross your edge.
System requirements
The platform asks for the building blocks a regulated team usually already runs. You bring the cluster and the backing services. CPU and memory scale with how many tenants and workloads you put on it, so size the install to your footprint rather than a fixed spec.
| Component | What it is for |
|---|---|
| Kubernetes cluster | A cluster you operate. The platform installs into a namespace via Helm. CPU and memory scale with the number of tenants and the workload you run. |
| Relational database | The system of record. Tenant isolation is enforced here with row-level security, so a database that supports it is required. |
| Object storage | A bucket for backups and exported evidence. Any S3-compatible store inside your boundary works. |
| Secrets store | A place to hold credentials and connector secrets. The platform reads them at runtime instead of baking them into images. |
| Container registry | An OCI registry you control to hold the mirrored platform images for air-gapped or restricted installs. |
These are the components, not a fixed bill of materials. The right CPU, memory, and storage depend on your tenant count and workload. The docs walk through sizing for an evaluation install and for production, so you plan against your own numbers.
Open and governed
You can self-host the platform and read its core. The governance does not loosen because you took the install in house. Isolation, the audit trail, and policy hold the same whether we host it or you do. Self-host changes the location, not the guarantees.
Isolation holds the same way
Database-enforced row-level security keeps one tenant from reading another, closed by default. The boundary does not soften because you run the install yourself.
The audit trail still proves itself
Every action is written once to a SHA-256 hash-chained trail. A quiet edit breaks the chain and shows, whether the platform is hosted by us or by you.
Policy runs where you run it
Your policy-as-code bundles evaluate inside your boundary, on your clusters, against the rules you set. Self-hosting moves the location, not the guarantee.
governance holds either way
Request a demo to see the platform working, then follow the docs to install it on your own Kubernetes, air-gapped if you need it. The portal, the engine, governed AI, and your evidence stay where you keep them.