Overview
Self-Managed Kindo (SMK) is the Kindo platform packaged for deployment inside your own Kubernetes cluster. This page answers three questions:
- Is SMK the right fit for your situation?
- What components make up the platform?
- What are you expected to bring?
Is SMK the right choice?
SMK is the right fit when you need control over where the platform runs or what it can reach. Kindo SaaS is the right fit when you do not. In one line: SaaS gets you running in minutes with no operational burden; SMK trades setup time for data residency and compliance boundaries.
Choose SMK if one or more of these applies:
| Driver | Why SMK fits |
|---|---|
| Data residency | All traffic and storage stay inside your network and region. |
| Regulatory compliance | Deploy into environments already certified for PCI-DSS, GDPR, HIPAA, FedRAMP, or similar. |
| Custom or proprietary models | Host your own fine-tuned or domain-specific models on your own GPUs. |
| Internal identity and audit | Audit logs, metrics, and SSO integration stay inside your environment. |
If none of those apply, SaaS is almost always the better choice — it is faster to adopt and Kindo operates it for you.
Feature Comparison
Both SaaS and SMK include the same core features:
| Feature | SaaS | Self-Managed |
|---|---|---|
| AI Chat | Yes | Yes |
| Agents (Chatbot, Workflow, Trigger) | Yes | Yes |
| Integrations (MCP) | Yes | Yes |
| DLP and Governance | Yes | Yes |
| RBAC | Yes | Yes |
| Audit Logging | Yes | Yes |
| SSO | Yes | Yes |
| API Access | Yes | Yes |
| DeepHat | Hosted | Self-hosted on your GPUs |
| Custom Model Hosting | No | Yes |
What ships vs. what you bring
| Layer | Component | Who provides it |
|---|---|---|
| Applications | api, next, litellm, task-worker-ts, ssoready, nango, credits, external-sync, external-poller, audit-log-exporter, cerbos (plus optional mcp-unified, sandbox) | Deployed by kindo-cli |
| Peripheries | Unleash (+ Edge), Qdrant, Presidio, Speaches, Hatchet, OTel Collector | Deployed by kindo-cli |
| Infrastructure | Kubernetes cluster (EKS, GKE, AKS, OpenShift, on-prem) | You (BYO) |
| Infrastructure | PostgreSQL (main + auxiliary) | You (BYO) |
| Infrastructure | Redis | You (BYO) |
| Infrastructure | RabbitMQ | You (BYO) |
| Infrastructure | S3-compatible object storage | You (BYO) |
| Infrastructure | DNS records and TLS certificates | You (BYO) |
| AI models | Cloud provider endpoints or self-hosted vLLM (including DeepHat) | You (BYO) |
The tool that drives it: kindo-cli
kindo-cli is the command-line installer and lifecycle manager for SMK. It generates two YAML files for you via an interactive wizard (kindo config init) — install-contract.yaml (what to deploy: version, domain, registry credentials, admin user) and environment-bindings.yaml (where your infrastructure is: database, cache, queue, and storage connection strings) — and then runs the install as a sequence of idempotent, resumable steps against your cluster. All install state is stored in Kubernetes itself, so any operator with cluster access can resume or re-run. The same binary handles upgrades, partial rebuilds, secret rotation, and diagnostics for the life of your deployment. See Install with kindo-cli for the full workflow.