Skip to content

Self-host Self-host ​

Self-host runs the whole product — control plane, proxy, dashboard and these docs — on infrastructure you operate, under an annual license. Nothing in a Self-host deployment needs a route to the internet: it installs from a signed bundle, checks its license offline, and sends model requests only where you point it.

It is sold as a yearly license, invoiced in advance; Plans & pricing has the terms. Talk to Intutic sales to start.

What runs ​

ServiceWhat it does
Control planeThe API, policies, traces, users and the license check
ProxyGoverns every LLM request your agents make
DashboardThe web app, served from your own address
DocsThis site, served at /docs/ on that address
PostgresYour data. Bundled with Docker Compose; bring your own on Kubernetes
ValkeyCaches and queues
nginx (Compose) or your Ingress (Kubernetes)One HTTPS address for all of the above

Optional: a semantic response cache (TurboVec) and a LiteLLM gateway in front of your own model server, which powers the LLM-backed checks (SOP scoring, the trajectory judge, compliance probes). Without one, those checks fall back to their deterministic versions.

What is different from Intutic Cloud ​

  • No sign-up. The installer creates the first owner; everyone else joins by invitation, SSO or SCIM.
  • No trials, no billing pages. The plan is the license: every feature, unlimited seats and requests, no per-request fee.
  • Cloud-only integrations are off, because they need the public internet: Stripe, the cloud marketplaces, the Notion and Google Drive connectors, the mem0 and Supermemory memory providers, VirusTotal lookups and product telemetry. Confluence and GitHub connectors work against your own Confluence Data Center or GitHub Enterprise Server.
  • Email goes through your relay (SMTP_URL). Without one, no email is sent and owners share sign-in details themselves.
  • Model requests go where you send them. Each provider's address is a setting (OPENAI_UPSTREAM_URL, ANTHROPIC_UPSTREAM_URL and so on): your private endpoint, your own model server, or an egress gateway.

Requirements ​

  • One hostname users can reach (for example intutic.example.internal) and a TLS certificate for it. The installer can issue a self-signed one to start.
  • Docker Compose: one Linux host, x86-64 or arm64, with 4 vCPUs, 16 GB of memory and 100 GB of disk, Docker Engine 24+ and Docker Compose v2, and openssl.
  • Kubernetes: a cluster running 1.27 or later, Helm 3, PostgreSQL 15 or later, and an Ingress controller.
  • Images: linux/amd64 and linux/arm64. Each tag at ghcr.io/intutic holds both; the air-gap bundle comes in one per architecture.

Getting a release ​

Each release is a signed bundle per architecture. Tell Intutic which yours is (uname -m: x86_64 is amd64, aarch64 is arm64), and you get time-limited links to three files: the bundle (intutic-selfhost-<version>-<arch>.tar.gz), its checksums (SHA256SUMS) and their signature (SHA256SUMS.sigstore.json). Verify the bundle where you downloaded it, before it goes into your network. You need cosign 3.0 or later and Intutic's public key, intutic-cosign.pub:

bash
cosign verify-blob --key intutic-cosign.pub --bundle SHA256SUMS.sigstore.json SHA256SUMS
tar -xzf intutic-selfhost-<version>-<arch>.tar.gz
cd intutic-selfhost-<version>
sha256sum -c ../SHA256SUMS

Check against ../SHA256SUMS, the copy you just verified, not the copy inside the bundle.

The bundle holds every image (images.tar), the installer, the Compose files and the Helm charts. On Kubernetes with registry access, the images and charts are also at ghcr.io/intutic, with a pull token Intutic issues to you.

Next ​

The circuit breaker for AI agents