--- sidebar_position: 5 question: Does an ABI production deploy require Kubernetes? kind: guide --- > **You are reading the v2.x docs (engine modules). New projects use v3.** [Read this page in v3](/capabilities/deploy/deployment-models) ยท [Migrate from 2.x to 3.0](/capabilities/upgrade/migrate-to-3) # Deployment models ABI's production stack is Docker Compose: every service is a standard container, with no proprietary Kubernetes substrate and no managed infrastructure required. For development, `abi dev up` runs the same engine as native processes. You operate it with tools you already know. This is an intentional design choice. Abstracting infrastructure into a managed runtime delivers security and availability guarantees but removes operator visibility and control. ABI makes the opposite tradeoff: the infrastructure is yours to inspect, modify, extend, and replace. You own operations. The same project runs on a developer laptop and in a production data center. The only differences between environments are the config files that select service backends, the model provider, and the LLM routing configuration. Your modules run inside the engine: deploying the engine deploys them. What sits next to it depends on the line: - **ABI 3.x, NATS project** (a `nats:` block in the config): the engine serves its kernel services over a [NATS broker](/architecture/real-time-fabric), and the bus and the [module jobs](/v2/capabilities/build/modules/module-jobs) use JetStream. - **ABI 2.x, and 3.x without NATS**: the bus is RabbitMQ (`services.bus`), and Dagster runs the orchestrations. | Model | For | How | |---|---|---| | Local development | One developer | `abi dev up`, or [Docker](/v2/capabilities/deploy/local-docker) | | One server | A team, a client, a staging environment | [Docker](/v2/capabilities/deploy/local-docker), or [Dokploy](/v2/capabilities/deploy/dokploy) on ABI 3.x | | Self-hosted production | Your cluster or data center | [Production](/v2/capabilities/deploy/production) | | Air-gapped | No outbound network | [Air-gapped](/v2/capabilities/deploy/air-gapped) | | Managed | naas.ai runs it | [naas.ai/enterprise](https://naas.ai/enterprise) | --- ## Local development Two ways to run a project on your machine: - **Native, no Docker:** `abi dev up` starts an Oxigraph server, the API (the engine, with your modules) and Nexus web as native processes, with file-based backends (SQLite, the file system). Each git worktree gets its own ports. On ABI 2.x it also starts Dagster. On ABI 3.x, in a NATS project it starts `nats-server` first (2.14 or later, on `PATH`) and leaves Dagster out; without NATS it starts Dagster when the project installs the `naas-abi-core[dagster]` extra. `--with-tracing` (ABI 3.x) needs `jaeger` on `PATH`. - **Docker Compose:** `abi deploy local` writes the project's stack, and `docker compose up -d` (or `abi stack start`) starts it: PostgreSQL, Fuseki, Qdrant, MinIO, Redis, the API, Nexus web, the MCP server and Caddy, with NATS on a NATS project (ABI 3.x) or RabbitMQ and Dagster without it. Step by step: [Quickstart](/user-guide/get-started/quickstart) and [Deploy with Docker](/v2/capabilities/deploy/local-docker). --- ## Self-hosted (on-premises) The production configuration. All services run in your infrastructure, nothing leaves your network. - Docker Compose on your servers, or your Kubernetes cluster (ABI ships no Kubernetes manifests or Helm chart: translate the Compose services yourself) - Your message broker (ABI 3.x, NATS project: NATS 2.14 or later, JetStream on; otherwise RabbitMQ), PostgreSQL, MinIO or S3, Redis, Fuseki and Qdrant - Your LLM infrastructure (Ollama cluster or private API endpoints) - Your SSL/TLS termination Things to plan for: - **One serving engine** (ABI 3.x, NATS project). One engine serves the kernel services per NATS account. For deploys without downtime, set `ABI_ROLLOUT_ID` per deploy and use shared backends (no SQLite or local files): the new engine stands by and takes over when the old one stops. See [one serving engine](/architecture/real-time-fabric#one-serving-engine). - **A supervisor.** Docker (`restart: unless-stopped`) or Kubernetes restarts what stops. In a NATS project (ABI 3.x) the API exits on purpose when the broker is unreachable for about two minutes. - **The broker stays private.** Traffic to NATS is not encrypted, and its monitoring port has no authentication; RabbitMQ is published on every interface by the generated stack. See [Security and compliance](/v2/capabilities/deploy/security-compliance#network-and-transport). This is the configuration naas.ai deploys for enterprise customers who require data residency compliance. How to set it up: [Production](/v2/capabilities/deploy/production); on one server with a domain, [Dokploy](/v2/capabilities/deploy/dokploy) (ABI 3.x). --- ## Air-gapped Full offline operation with locally-run models: - Ollama serves LLM inference from a local model library; the `ai.ollama` module registers Qwen2.5 3B and `nomic-embed-text`, and the marketplace has modules for Qwen3 8B, DeepSeek R1 8B and Gemma3 4B - No calls to OpenAI, Anthropic, OpenRouter or any external API: disable the cloud provider modules - `ai_mode: "local"` (or `"airgap"`) in `config.yaml`, with the model registry defaults pointed at the local models - Images, Python packages and models are brought in beforehand The steps are in [Air-gapped](/v2/capabilities/deploy/air-gapped). --- ## Managed (naas.ai) The open-source core is MIT-licensed, with no license key. naas.ai can deploy and operate it with you, on your premises or on naas.ai infrastructure. See [naas.ai/enterprise](https://naas.ai/enterprise). --- ## Configuration per environment A project made by `abi new project` keeps one config file per environment: ```text title="Project root" config.yaml # Default: what `abi dev up` and the CLI read config.local.yaml # The Docker Compose stack (its `abi` service sets ENV=local) config.remote.yaml # A remote deployment ``` The engine reads `config..yaml` when the `ENV` environment variable names one that exists, else `config.yaml`. On ABI 3.x, `ABI_CONFIG_OVERLAY` merges a YAML file over it (`abi dev up` uses it for its broker settings). See [Configuration Reference](/user-guide/get-started/configuration). --- ## Enterprise reference architectures :::info Professional services implementation Enterprise architectures (Kubernetes, multi-region, government networks) are designed and implemented with naas.ai's professional services team, for each environment. Contact [support@naas.ai](mailto:support@naas.ai) to discuss your needs and timeline. ::: Whatever the platform, the rules of [self-hosted production](#self-hosted-on-premises) hold: a broker on a private network, a supervisor that restarts what stops, and, in a NATS project (ABI 3.x), one NATS broker with JetStream, one serving engine per NATS account and shared backends for deploys without downtime. Also: - **The engine is not a replica set** (ABI 3.x, NATS project). One engine serves the kernel services per NATS account. A second engine with the same rollout id fails with `EngineAlreadyServing`; with a new `ABI_ROLLOUT_ID` it stands by for a deploy. - **Images.** The ABI repository publishes `ghcr.io/jupyter-naas/abi` and `ghcr.io/jupyter-naas/nexus-web`. A project builds its own `abi` image from its `Dockerfile`, since it carries the project's modules. - **Managed backends.** PostgreSQL, Redis and S3-compatible storage can be your cloud's managed services: ABI talks to them through its standard adapters. Nothing in ABI is specific to one cloud. - **Identity.** ABI has no built-in SAML, LDAP, OpenID Connect or MFA. Put an identity-aware proxy in front. See [Security and compliance](/v2/capabilities/deploy/security-compliance). - **Compliance.** ABI holds no attestation (FedRAMP, SOC 2, ISO 27001 or other). A deployment is assessed as a whole. See [Compliance frameworks](/v2/capabilities/deploy/security-compliance#compliance-frameworks). - **Multi-region.** ABI ships no clustered broker configuration and no cross-region replication. Availability comes from the infrastructure under the stores and the broker. See [High availability](/v2/capabilities/deploy/high-availability).