Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.trynebula.ai/llms.txt

Use this file to discover all available pages before exploring further.

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

Kubernetes

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.

Docker 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.

Decision tree

Use EKS + Karpenter + the Helm chart with managed AWS 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.
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 and Managed AWS resources.
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 shows the structural choices to make.
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.
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.

What ships in every bundle

FilePath A (K8s)Path B (Compose)
images.tarSide-load + push to your registrySide-load with docker load
helm/nebula-<version>.tgzThe chart you helm install
helm/values.example.yamlSchema reference
helm/examples/eks/values.yamlReference values for EKS + RDS + S3 + Karpenter
compose.enterprise.yamlThe Compose deploy file
compose.vllm.yamlAir-gapped overlay (in-stack vLLM)
enterprise/bootstrap.sh./bootstrap.sh entry point
enterprise/generate-secrets.sh(use ESO / Secrets Manager instead)Generates .env.enterprise
cosign-signatures/Offline image-provenance verificationOffline image-provenance verification
sbom.spdx.jsonSBOM for security reviewSBOM 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: helm upgrade nebula ./helm/nebula-X.Y.Z.tgz -f your-values.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. The Compose bundle runs catalog-bootstrap automatically; the current Helm chart still needs an external migration/catalog-bootstrap step before API pods serve traffic.