Spice runs as a single binary, a container, a Kubernetes workload, or a fully managed app on the Spice Cloud Platform. This guide helps choose a target environment and a deployment architecture to match an application's latency, scale, and operational requirements.
Most users fall into one of three groups:
:::tip Self-hosted enterprise deployments
For production self-hosted clusters, the Spice.ai Enterprise Kubernetes Operator provides per-replica StatefulSets, automatic PVC resizing, configurable update strategies, crashloop protection, and distributed query execution through SpicepodSet and SpicepodCluster custom resources.
:::
Architecture refers to where Spice runs in relation to the application and data sources, and how it scales. Pick an architecture before choosing a guide; the same target environment can host any of these patterns.
Step-by-step instructions for each target environment.
| Guide | When to use |
|---|---|
| Kubernetes | Self-hosted production deployments. Covers Helm, Argo CD, and Flux. |
| Docker | Local development, single-host deployments, and container-based pipelines. |
| Spice Cloud | Fully managed deployments without operating infrastructure. |
| AWS | Deployments on AWS using the published CloudFormation template. |
| Azure | Deployments on Azure using ARM/Bicep templates. |
| GCP | Deployments on Google Cloud using GKE, Cloud Run, or Compute Engine. |
| CI/CD | Automating any of the above through pipelines or GitOps. |
| Read/Write Separation | Production pattern that splits ingest from reads using shared snapshots. |