Built-in State Store
July 8, 2026
Snap CD 1.7.1 introduces the State Store — encrypted, centrally managed Terraform / OpenTofu state built into the Server.
Why
Snap CD does not prescribe where you store your Terraform state. You can use any remote backend — S3, Azure Blob, GCS, Terraform Cloud, or anything else Terraform supports. But you do need some remote backend: Runners are stateless and potentially ephemeral, so local state is not practical.
Until now, that meant standing up and maintaining a separate storage service for your state files — provisioning the bucket, configuring access policies, managing encryption keys, and wiring backend configuration into every Module. The built-in State Store removes that requirement. State can now be stored directly in Snap CD, encrypted at rest with AES-256-GCM, access-controlled via role assignments, and versioned per state file — all without provisioning any additional infrastructure.
How to configure it
The State Store exposes Terraform's HTTP backend API. You configure it at the Namespace level using Snap CD resources you already know — Extra Files, Flags, and Array Flags — so every Module in the Namespace gets its own state file automatically. Your Terraform code stays untouched; the backend configuration is injected by the Runner at init time, consistent with Snap CD's non-invasive approach.
Authentication uses the Runner's service principal credentials, injected via the new Runner Environment Variables setting. No per-module credential wiring is needed — configure SNAPCD_CLIENT_ID and SNAPCD_CLIENT_SECRET once on the Runner's appsettings.json, and every Module in the Namespace authenticates automatically.
Every Organization is pre-seeded with a default State Store. Additional State Stores can be created to isolate state across environments or teams.
Access control
Access to State Stores is governed by the same RBAC that controls Stacks, Namespaces, Modules, Runners, and Agents. Role assignments (Owner, Contributor, Reader, IdentityAccessManager) can be granted to Users, Service Principals, or Groups — all manageable via the Terraform Provider.
State file locking is built in: concurrent applies to the same state file are blocked until the lock is released. Locks auto-expire after a configurable timeout (default 30 minutes).
What if I already use S3 / Azure / GCS?
Keep using it. The State Store is one option, not a migration. Snap CD's orchestration works the same regardless of which backend your Modules use. You can mix backends within the same organization — some Namespaces using the built-in State Store, others using S3 or Azure Blob.
Server configuration
The State Store requires a StateStore:EncryptionKey in the Server's appsettings.json — a base64-encoded 256-bit key used for AES-256-GCM encryption at rest. The Server will refuse to start if this key is missing. The example deployments (Docker, Kubernetes, local) ship with a default key for development; production deployments should generate their own via openssl rand -base64 32.
Getting started
- State Store documentation — full setup recipe including the backend configuration resources
- Runner Environment Variables — configuring credentials for the HTTP backend
- The sample-deployment uses the State Store end-to-end (section 2 in
module/main.tf)
Intelligent GitOps for Infrastructure as Code. Automate, orchestrate, and scale your infrastructure deployments with confidence.
© 2026 Snap CD. All rights reserved.