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

Self-host

Run the whole platform on infrastructure you control.

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

Run it on 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.

Helm install your cluster
  • helm install integraci ./integraci
  • namespace integraci ready
  • portal deployment running
  • engine deployment running

deployed to infrastructure you own

Your boundary air-gapped

inside the edge

  • portal + engine
  • OCI registry (mirrored)
  • model (self-hosted)
  • evidence + audit
outbound to public internet none

nothing leaves the boundary

Air-gapped

Air-gapped when you need it.

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

What it takes to run.

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.

Sized to your footprint

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

What is open, what stays 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.

Hosted or self-hosted same guarantees
  • deployment self-host to air-gapped your control
  • tenant isolation RLS + FORCE enforced
  • audit trail hash-chained tamper-evident
  • policy policy bundles your rules

governance holds either way

Keep it inside your boundary.

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.