> ## Documentation Index
> Fetch the complete documentation index at: https://docs.zeroset.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Deploying Nebula Enterprise — choosing between Kubernetes and Docker Compose

Nebula Enterprise ships as a signed bundle (`nebula-enterprise-<version>.tar.gz`) containing every image, the Helm chart, the Docker Compose stack, and the bootstrap tooling for both deploy paths. The bundle is identical regardless of which path you choose — same application binaries, same database schema, same release-contract attestations.

## Two supported deploy paths

<CardGroup cols={2}>
  <Card title="Kubernetes" icon="kubernetes" href="/enterprise/kubernetes/eks">
    **Recommended for production.** Helm chart consumed by EKS, GKE, AKS, or on-prem K8s. Same artifact we run our own staging and production on. Best autoscaling story (Karpenter on EKS), best LB integration, cleanest upgrade story.
  </Card>

  <Card title="Docker Compose" icon="docker" href="/enterprise/compose">
    **Recommended for air-gapped, single-VM, or POC deployments.** `./bootstrap.sh` brings up the full stack on one host in \~5 minutes. Same binaries; everything you build on this path is forward-compatible with the K8s path.
  </Card>
</CardGroup>

## Decision tree

<AccordionGroup>
  <Accordion title="You're on AWS and have a platform team that runs K8s">
    Use **EKS + Karpenter + the Helm chart** with [managed AWS resources](/enterprise/managed-resources) (RDS + S3). This is the path the bundle's release pipeline is tuned for; upgrades are `helm upgrade` against each new bundle. See the [EKS deploy guide](/enterprise/kubernetes/eks).
  </Accordion>

  <Accordion title="You're on AWS but don't have a K8s platform yet">
    Start on **Docker Compose pointed at RDS + S3**. Compose host on ECS-on-EC2 or a single EC2 instance; managed Postgres + real S3 give you the operational durability of the K8s path without standing up a cluster. When you outgrow it, migrate to EKS — the data plane is identical. See [Compose](/enterprise/compose) and [Managed AWS resources](/enterprise/managed-resources).
  </Accordion>

  <Accordion title="You're on GCP or Azure">
    Use the Helm chart against GKE or AKS. The chart is cloud-agnostic by default: leave `karpenter.enabled` false (use Cluster Autoscaler / GKE NAP / AKS autoscaler instead), swap `storageClass.name` for your platform's CSI default, swap `ingress.className` for `gce` / `azure-application-gateway`. Use `helm/values.example.yaml` as the schema reference; the [EKS guide](/enterprise/kubernetes/eks) shows the structural choices to make.
  </Accordion>

  <Accordion title="You're on bare metal or air-gapped (no cloud)">
    Use **Docker Compose** with the optional `compose.vllm.yaml` overlay for a local LLM (no internet egress required for inference). Single-host deploy via `./bootstrap.sh`. Bundle ships every image inside `images.tar` — no registry pull. See [Compose](/enterprise/compose).
  </Accordion>

  <Accordion title="You just want to evaluate the product">
    Use **Docker Compose** on a single VM. `./bootstrap.sh` works in \~5 minutes with no AWS account, no K8s cluster, no managed-resource prereqs. Migrate to your production path when you've validated the fit.
  </Accordion>
</AccordionGroup>

## What ships in every bundle

| File                             | Path A (K8s)                                      | Path B (Compose)                                  |
| -------------------------------- | ------------------------------------------------- | ------------------------------------------------- |
| `images.tar`                     | Imported by `./nebula-enterprise images import`   | Side-load with `docker load`                      |
| `bundle-manifest.json`           | Machine-readable image inventory                  | Machine-readable image inventory                  |
| `nebula-enterprise`              | Image import + managed-resource validation helper | Image import + managed-resource validation helper |
| `enterprise/install-k8s.sh`      | One-env-file EKS install wrapper                  | —                                                 |
| `helm/nebula-<version>.tgz`      | The chart you `helm install`                      | —                                                 |
| `helm/values.example.yaml`       | Schema reference                                  | —                                                 |
| `helm/examples/eks/values.yaml`  | Reference values for EKS + RDS + S3 + Karpenter   | —                                                 |
| `compose.enterprise.yaml`        | —                                                 | The Compose deploy file                           |
| `compose.vllm.yaml`              | —                                                 | Air-gapped overlay (in-stack vLLM)                |
| `enterprise/bootstrap.sh`        | —                                                 | `./bootstrap.sh` entry point                      |
| `enterprise/generate-secrets.sh` | (use ESO / Secrets Manager instead)               | Generates `.env.enterprise`                       |
| `attestations/`                  | Offline image-provenance verification             | Offline image-provenance verification             |
| `sbom.spdx.json`                 | SBOM for security review                          | SBOM for security review                          |

## Versioning + upgrades

Bundles are tagged `enterprise-vX.Y.Z`. New bundles ship on a cadence driven by feature work and CVE response (see the `SECURITY.md` inside each bundle for the responsible-disclosure contact and supported-version policy). Upgrade path:

* **K8s**: run `./nebula-enterprise images import` for the new bundle, then `helm upgrade nebula ./helm/nebula-X.Y.Z.tgz -f your-values.yaml -f helm/values.images.generated.yaml`. Rolling update; no downtime for the API tier.
* **Compose**: extract the new bundle alongside the old one, `docker load -i images.tar`, update `NEBULA_VERSION` in `.env.enterprise`, re-run `./enterprise/bootstrap.sh`. Single-host restart; \~30s downtime.

Both paths are forward-compatible: data written on `vX.Y.0` is readable by `vX.Y+1.0` after migrations run. Compose runs catalog-bootstrap automatically; Helm runs schema migrations and catalog-apply through the chart's per-revision migration Job before API and worker pods serve traffic.