> For the complete documentation index, see [llms.txt](https://k-ai.gitbook.io/knowledge-ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://k-ai.gitbook.io/knowledge-ai/the-k-ai-platform/deployment.md). # Deployment models K-AI supports three deployment modes; the choice is driven by customer context (residency, ops responsibility, regulatory constraint). All three run the same platform code — only the substrate differs. ## SaaS (multi-tenant) Hosted on managed Kubernetes in France. Per-customer Kubernetes pods inside a shared cluster, with full pod-level isolation. Standard ingress with automated TLS termination. Customer URLs are exposed under `.kai-studio.ai` (per-subdomain routing for the management and API surfaces). The SaaS mode is operated by K-AI. No customer infrastructure is required. Onboarding a new customer creates a new K-AI Instance — a new pod, a new Postgres schema, a new vector index, a new storage bucket — all isolated from every other customer (see [Security & isolation](/knowledge-ai/the-k-ai-platform/security.md)). Time-to-first-document is typically same-day once the connector configuration is agreed. Data residency: France. EU residency available on request. ## On-premise Identical Kubernetes architecture deployed in the customer's own cluster. Templates, procedures, hardware requirements, and installation guides ship with the platform — see [Operate — On-premise installation](/knowledge-ai/operate/on-premise.md) for the build-and-deploy walkthrough. The on-premise mode supports **air-gapped environments**: bundled deployment scripts produce and consume offline Docker image archives, so a deployment in a network without internet egress is a supported path rather than an exception. Customers control their own update cadence and can pin specific platform versions. Operations responsibility is on the customer (or the customer's chosen integration partner). K-AI provides reference templates, runbooks, and remote support. ## Snowflake Native App (SPCS) Deployed as Snowflake Container Services inside the customer's own Snowflake account. Documents live in Snowflake Stages, embeddings in `VECTOR` columns, management metadata in dedicated schemas. **Data never leaves Snowflake** — this is the architectural property that drives the choice for customers with Snowflake-resident document policies. The Snowflake Native App is a regular Snowflake Marketplace listing in the customer's region of choice; deployment is initiated from the customer's Snowflake account. A Tier-1 logistics group runs K-AI on Snowflake Native App today. The Snowflake mode is the most constrained of the three: it inherits Snowflake's resource model (warehouses, compute pools, account-level governance) and its operational SLA. In return it inherits Snowflake's compliance footprint at the substrate level. ## Comparison | Mode | Residency | Ops responsibility | Time-to-deploy | Integration constraints | Compliance fit | | ------------------------ | ----------------------------------------------------------------------- | --------------------------------------------- | --------------------------------------------- | ------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | **SaaS** | France (EU residency on request) | K-AI | Same day for first instance | Outbound HTTPS to connector sources | GDPR-aligned; default for EU customers without specific residency mandates | | **On-premise** | Customer-controlled (any region, any data center, air-gapped supported) | Customer (or integration partner) | Days to weeks (depends on cluster readiness) | Customer cluster must meet sizing requirements; air-gapped deployments use offline image archives | Required for highly classified data (e.g. *secret-défense* in the French defence sector), classified environments, and most public-sector mandates | | **Snowflake Native App** | Customer's Snowflake region | Customer (within Snowflake's operating model) | Hours once the Marketplace listing is enabled | Customer must have an active Snowflake account; document estate must be (or be made) Snowflake-resident | Aligned with customers whose data policy mandates Snowflake residency (BFSI, large enterprises with Snowflake-first data strategies) | ## Next steps For ops-grade depth — sizing tables, monitoring stacks, backup and restore procedures, upgrade paths — see [Operate — Deployment models](/knowledge-ai/operate/deployment-models.md). For the on-premise installation walkthrough specifically, see [Operate — On-premise installation](/knowledge-ai/operate/on-premise.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://k-ai.gitbook.io/knowledge-ai/the-k-ai-platform/deployment.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.