--- sidebar_position: 5 question: Does an ABI production deploy require Kubernetes? kind: guide --- # 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. Since 3.0 every deployment runs on a [NATS broker](/architecture/real-time-fabric): the engine serves its kernel services over it, the bus and the [module jobs](/user-guide/build/modules/module-jobs) use JetStream, and remote modules run in their own containers next to the engine. | Model | For | How | |---|---|---| | Local development | One developer | `abi dev up`, or [Docker](/user-guide/deploy/local-docker) | | One server | A team, a client, a staging environment | [Docker](/user-guide/deploy/local-docker) or [Dokploy](/user-guide/deploy/dokploy) | | Self-hosted production | Your cluster or data center | [Production](/user-guide/deploy/production) | | Air-gapped | No outbound network | [Air-gapped](/user-guide/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 `nats-server`, an Oxigraph server, the API, Nexus web and the remote modules listed under `dev.modules`, as native processes with file-based backends (SQLite, the file system). Each git worktree gets its own ports. It needs `nats-server` 2.14 or later on `PATH`, and `jaeger` for `--with-tracing`. - **Docker Compose:** `abi deploy local` writes the project's stack, and `docker compose up -d` (or `abi stack start`) starts it: NATS, PostgreSQL, Fuseki, Qdrant, MinIO, Redis, the API, Nexus web, the MCP server and Caddy. Remote modules each get a service in `docker-compose.override.yml`. Step by step: [Quickstart](/user-guide/get-started/quickstart) and [Deploy with Docker](/user-guide/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 NATS server (2.14 or later, JetStream on), 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.** 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.** The API and remote modules exit when the broker is unreachable for about two minutes; Docker (`restart: unless-stopped`) or Kubernetes restarts them. - **The broker stays private.** Traffic to NATS is not encrypted, and its monitoring port has no authentication. See [Security model](/developer-guide/architecture/security). - **Remote modules** scale on their own: several replicas of a module share its agent runs and its jobs. This is the configuration naas.ai deploys for enterprise customers who require data residency compliance. How to set it up: [Production](/user-guide/deploy/production); on one server with a domain, [Dokploy](/user-guide/deploy/dokploy). --- ## 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](/user-guide/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`. `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: one NATS broker with JetStream on a private network, one serving engine per NATS account, shared backends for deploys without downtime, and a supervisor that restarts what exits when the broker is gone. Also: - **The engine is not a replica set.** 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. Scale out with remote modules, not engine replicas. - **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](/user-guide/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](/user-guide/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](/user-guide/deploy/high-availability).