Spice.ai provides multiple deployment options on Microsoft Azure, enabling data and AI applications to run on Azure's global infrastructure. Whether using virtual machines, container orchestration, or serverless containers, Spice deploys to meet requirements for performance, scalability, and cost efficiency.
For a complete list of Azure-compatible data connectors, AI models, and integrations, see Azure Integrations (opens in a new tab).
Run Spice.ai on Azure Kubernetes Service (opens in a new tab) when the workload benefits from Kubernetes orchestration, multi-replica scale, declarative configuration, or shared cluster tenancy. AKS pairs well with the Spice Helm chart (opens in a new tab) and the Argo CD (opens in a new tab) or Flux (opens in a new tab) GitOps workflows.
Provision an AKS cluster with workload identity (opens in a new tab) and the OIDC issuer (opens in a new tab) enabled — both are required for federated credentials to Azure services.
For burst or low-utilization workloads, attach virtual nodes (opens in a new tab) backed by Azure Container Instances. For production, prefer Bicep or Terraform for repeatable provisioning — the Azure Verified Modules (opens in a new tab) library publishes a maintained AKS module.
The ABFS connector and the azure_keyvault secret store can authenticate with an Azure identity instead of a static secret. Use workload identity (opens in a new tab) so pods receive scoped, federated tokens without static secrets:
Reference the identity from the Helm release. Workload identity then injects AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_FEDERATED_TOKEN_FILE into the pod. The ABFS connector reads them automatically, and the azure_keyvault secret store uses them when auth_method is workload_identity (see Authentication (opens in a new tab)):
For declarative GitOps, swap this command for an Argo CD Application or a Flux HelmRelease pointing at the same chart. See the Argo CD (opens in a new tab) or Flux (opens in a new tab) guides for full manifests.
For stateful acceleration (DuckDB, SQLite, Cayenne):
local-storage StorageClass, or through Azure Container Storage (opens in a new tab)'s local-csi class. Local NVMe does not survive node replacement, so pair with a refresh strategy or a re-hydration source. Local NVMe Storage (opens in a new tab) walks through the AKS setup step by step — VM sizes, mounting the disks, the provisioner, the chart values, and verification.skuName: PremiumV2_LRS).managed-csi-premium) — use the built-in managed-csi-premium storage class only when Premium SSD v2 is unavailable in a region.azurefile-csi) — not recommended for acceleration — use only for stateless shared artefacts that need ReadWriteMany. SMB/NFS latency negates the benefit of using a local accelerator.stateful.enabled: true and stateful.storageClass: <chosen-class> in values.yaml.:::tip[Spice.ai Enterprise]
For production stateful workloads, the Spice.ai Enterprise (opens in a new tab) Operator's SpicepodSet (opens in a new tab) provides per-replica StatefulSets with automatic PVC resizing, workload-identity-aware ServiceAccount annotations, and configurable update strategies. For distributed query execution across scheduler/executor tiers backed by Azure Blob Storage, see SpicepodCluster (opens in a new tab).
:::
To expose Spice externally, install the Application Gateway Ingress Controller (AGIC) (opens in a new tab) or use a Standard public Load Balancer (opens in a new tab):
For internal-only deployments, set azure-load-balancer-internal: "true" to bind to the cluster's VNet rather than a public IP.
The Spice Helm chart ships a PodMonitor resource for the Prometheus Operator (opens in a new tab). On AKS, the Azure Monitor managed service for Prometheus (opens in a new tab) and Container insights (opens in a new tab) are the common targets. Set monitoring.podMonitor.enabled: true and import the Spice Grafana dashboard (opens in a new tab) into Azure Managed Grafana (opens in a new tab).
For comprehensive guidance, refer to the Azure Kubernetes Service documentation (opens in a new tab), the AKS baseline architecture (opens in a new tab), and the Spice.ai Kubernetes Deployment Guide (opens in a new tab).
Azure Container Apps (opens in a new tab) is a serverless container platform suitable for HTTP-driven Spice.ai workloads that benefit from scale-to-zero and request-based autoscaling. Use it when a single managed container is sufficient and operating Kubernetes is not desired.
The environment is the security and networking boundary that hosts one or more container apps:
To reach Azure SQL, Storage, or Key Vault behind private endpoints, attach the environment to a VNet-injected subnet (opens in a new tab) by adding --infrastructure-subnet-resource-id and --internal-only true.
Container Apps support both system-assigned and user-assigned managed identities (opens in a new tab). A user-assigned identity is preferred so role assignments survive app recreation:
Mount Azure Files (opens in a new tab) for stateful acceleration, inject secrets from Key Vault (opens in a new tab), and configure HTTP ingress on port 8090:
The spiceai/spiceai image starts spiced with no arguments, and spiced then listens only on 127.0.0.1 (port 8090 for HTTP and 50051 for Arrow Flight), which ingress cannot reach. The Azure CLI parses values that begin with -- as its own options, so set the container's arguments in the app's YAML instead of with --args. Export the app:
In spiceai.yaml, add an args list to the container under properties.template.containers:
Then apply it, which creates a new revision:
Add --metrics and 0.0.0.0:9090 to the list to serve Prometheus metrics.
With --ingress external, the app is reachable from the internet. Before deploying, configure API key authentication (opens in a new tab) (runtime.auth) in the Spicepod, or use private networking instead: without runtime.auth, any caller that reaches the runtime can query its data and call its state-changing routes.
To run multiple replicas with shared file-based acceleration, define an Azure Files storage mount (opens in a new tab) and reference it from the app's revision template, then point file accelerators at the mount path (for example, duckdb_file: /data/taxi_trips.db).
Spice.ai is HTTP-driven, so the default HTTP scale rule (opens in a new tab) (concurrent requests per replica) is usually sufficient. For background workloads (refresh schedules, ingestion) that should not scale to zero, set --min-replicas 1 and add a custom scale rule (opens in a new tab) backed by a CPU or queue metric:
Configure the liveness and readiness probes (opens in a new tab) to use /health and /v1/ready. Container Apps creates a new revision (opens in a new tab) on each update, supporting traffic splitting between revisions for canary upgrades:
For more details, see the Azure Container Apps documentation (opens in a new tab) and the Spice.ai Docker Deployment Guide (opens in a new tab).
Run Spice.ai as a single container without provisioning a cluster using Azure Container Instances (opens in a new tab). Suitable for development environments, scheduled jobs, and low-traffic deployments.
The --command-line replaces the image's start command, so it names /usr/local/bin/spiced before its arguments. Without --http 0.0.0.0:8090 and --flight 0.0.0.0:50051, spiced listens only on 127.0.0.1, which the container's public IP address cannot reach.
With --ip-address public, the container is reachable from the internet. Before deploying, configure API key authentication (opens in a new tab) (runtime.auth) in the Spicepod, or use private networking instead: without runtime.auth, any caller that reaches the runtime can query its data and call its state-changing routes.
Refer to the Azure Container Instances documentation (opens in a new tab) for advanced networking, virtual network integration (opens in a new tab), and managed identity (opens in a new tab) configuration.
Deploy Spice.ai directly on Azure Virtual Machines (opens in a new tab) for maximum control over the environment, GPU access, or large-memory instance types.
Manual VM deployment:
spice binary directly. See the installation guide (opens in a new tab).Automated deployment with Bicep or Terraform:
For detailed guidance, refer to the Linux on Azure documentation (opens in a new tab), Bicep documentation (opens in a new tab), and Azure provider for Terraform (opens in a new tab).
Most Azure services that Spice connects to accept explicit credentials through component parameters (for example, an abfs_access_key on the ABFS connector (opens in a new tab)). Spice does not use the Azure Identity DefaultAzureCredential (opens in a new tab) chain. Each component resolves Azure credentials on its own.
Azure Blob Storage and ADLS Gen2. The ABFS connector first validates its explicit abfs_* authentication parameters, whether set in the Spicepod or loaded from a secret store under the same name. They must name at most one method: abfs_access_key, abfs_bearer_token, abfs_sas_string, client credentials, abfs_use_cli: true, abfs_msi_endpoint, abfs_federated_token_file, or abfs_skip_signature: true. Client credentials need all three of abfs_client_id, abfs_client_secret, and abfs_tenant_id. Otherwise the dataset fails to load with Multiple authentication methods were provided or Incomplete client credentials. The check reads only abfs_* parameters, so abfs_client_id with the tenant ID and secret in AZURE_* environment variables fails as incomplete.
After validation, the connector starts from the AZURE_* environment variables, such as AZURE_STORAGE_ACCOUNT_KEY, AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_CLIENT_SECRET, and AZURE_FEDERATED_TOKEN_FILE, and lets each abfs_* parameter override the matching value. With no abfs_* authentication parameters, the environment alone supplies the credential, as with AKS workload identity. It uses the first credential that is fully configured, in this order:
az login, only when abfs_use_cli is true.AZURE_CLIENT_ID, selects a user-assigned identity.The ABFS connector does not use certificate credentials (AZURE_CLIENT_CERTIFICATE_PATH), a username and password, the Azure Developer CLI, or Azure PowerShell.
Azure Key Vault. The azure_keyvault (opens in a new tab) secret store chooses its credential with the auth_method parameter. The default, default, uses a service principal when client_secret is set, and otherwise the Azure CLI or Azure Developer CLI login. The store uses a managed identity or workload identity only when auth_method is managed_identity or workload_identity.
Azure SQL and Azure OpenAI. The MSSQL connector (opens in a new tab) authenticates with a SQL Server login, and Azure OpenAI models (opens in a new tab) authenticate with azure_api_key or azure_entra_token. Neither reads an Azure identity from the environment.
:::note[Role assignments]
Regardless of the credential source, the principal must have the appropriate Azure role assignments (for example, Storage Blob Data Reader on a storage account, or Key Vault Secrets User on a key vault). When a Spicepod connects to multiple Azure services, the principal must have permissions across all of them.
:::
Spice.ai is not yet published to the Microsoft Azure Marketplace (opens in a new tab) (coming soon). In the meantime, deploy using the spiceai/spiceai (opens in a new tab) container image or the Spice Helm chart (opens in a new tab).