Stores Configuration
The stores section in atmos.yaml configures external key-value stores that can be used to share data between components using the !store YAML function and hooks. Any store can also be marked sensitive with secret: true to make it a secret backend — a great place to keep API keys, tokens, and passwords — resolved with the !secret function and the atmos secret CLI.
Configuration
Store Name Convention
Store names follow the pattern <environment>/<type> by convention:
prod/ssm- Production SSM Parameter Storedev/secrets- Development Secrets Managershared/config- Shared configuration store
You can reference stores in stack configuration using the !store function:
vars:
database_password: !store prod/secrets::database/password
api_key: !store prod/ssm::/app/api-key
Supported Store Kinds
Use kind for new store definitions. The legacy type field is still accepted for
backward compatibility; when both are set, kind wins.
aws/ssm(legacy type:aws-ssm-parameter-store)- AWS Systems Manager Parameter Store. Stores and retrieves parameters from SSM.
aws/asm(legacy type:aws-secrets-manager)- AWS Secrets Manager. Stores and retrieves string or JSON secret values.
azure/keyvault(legacy type:azure-key-vault)- Azure Key Vault. Stores and retrieves secrets from Azure.
gcp/secretmanager(legacy types:google-secret-manager,google/secretmanager,gsm)- Google Cloud Secret Manager. Stores and retrieves secrets from GCP.
redis- Redis key-value store. Useful for caching and temporary data.
artifactory- JFrog Artifactory. Stores and retrieves data as JSON files. Use a Generic repository type.
github-actions(kind:github/actions)- GitHub Actions secrets. Writes, lists, and deletes secrets through the GitHub API; secret values can only be read back inside a GitHub Actions runner (the API never returns them). Best suited as a distribution target so workflows consume secrets via the native
secretscontext.
Secret Stores
Stores are an excellent place to keep secrets. Mark any store sensitive by setting secret: true, and it becomes a secret backend:
A secret: true store:
- Writes the sensitive at-rest variant of its backend (e.g. SSM
SecureString, Key Vault secret). - Masks values automatically in command output, so secrets don't leak into logs the way a plain
!storevalue can. - Is resolved only with
!secretand theatmos secretCLI — using!store,!store.get, oratmos.Storeagainst asecret: truestore is an error, which keeps the declarative secret registry mandatory by construction.
Some backends are secret managers by nature (1Password, the OS keychain, GitHub Actions) and default to secret: true even when you omit it. For declaring, provisioning, and reading secrets, see Secrets Configuration.
secret: true is rejected at startup for backends that store values in plaintext — currently Redis (an in-memory cache) and Artifactory (an artifact repository). Marking one of these sensitive would give a false sense of security, so Atmos fails fast with a clear error rather than writing secrets in the clear. Use an encrypted backend instead: AWS SSM (SecureString), AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault, 1Password, the OS keychain, or GitHub Actions.
Store Type Configuration
AWS SSM Parameter Store
AWS Secrets Manager
Azure Key Vault
Authentication uses the Azure Default Credential chain, which checks environment variables, managed identity, Azure CLI, and other sources.
Google Secret Manager
Floci Local Endpoints
For local Floci-backed store tests, configure the AWS auth identity endpoint
under auth.identities.*.spec.endpoint_url and configure GCP/Azure emulator
endpoints on the store options:
Redis
The url option supports Redis URL format including authentication: redis://:password@host:port/db
Artifactory
The access_token can be provided directly, via the !env function, or through the ARTIFACTORY_ACCESS_TOKEN environment variable.
When setting up Artifactory as a store backend, create a Generic repository type in JFrog Artifactory. Atmos stores data as JSON files, so no specific package type (Maven, npm, Docker, etc.) is required. The repository can be local, remote, or virtual.
GitHub Actions
GitHub Actions secrets are a "native CI" backend. Because the GitHub API never returns a secret's value, this store is asymmetric:
- Write / list / delete go through the GitHub API and work anywhere a token is available.
- Existence checks (
atmos secret list) work everywhere — the API reports whether a secret is initialized (and when it was last updated) without exposing the value. - Reading a value only works inside a GitHub Actions runner, where GitHub injects the secret into the environment. Outside a runner the read fails with a clear error; gate it with
ci.enabledfor non-runner contexts.
Secret names are flat and repo-global: a key is written as [PREFIX_]KEY uppercased (e.g. db_password → DB_PASSWORD), so the same key resolves to the same GitHub secret across stacks and components. To read a value inside a workflow, map the secret into the job environment under the same name so the env-based read can find it:
# .github/workflows/deploy.yml
jobs:
deploy:
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
steps:
- run: atmos terraform apply vpc -s prod # !secret resolves DB_PASSWORD from the env
The token is resolved from the token option, then ATMOS_PRO_GITHUB_TOKEN, ATMOS_GITHUB_TOKEN, and GITHUB_TOKEN (in that order). Only api.github.com is targeted; GitHub Enterprise Server is not yet supported.
Alignment warnings
When a value is read inside a runner, Atmos emits warnings (never errors) if the runner's context doesn't match the store config, so misconfigurations surface early:
- Repository mismatch — if
GITHUB_REPOSITORYdiffers from the store'sowner/repo, the injected secrets come from a different repository than the store targets. - Environment mismatch — GitHub doesn't expose the job's
environment:name as a plain variable, but it is present in the GitHub Actions OIDC token (environmentclaim). When the store hasenvironment:set, Atmos best-effort mints and decodes that token to verify the job is actually running in the matching environment. This requires the job to grantpermissions: id-token: write; without it, the check is skipped silently.
jobs:
deploy:
environment: production # binds the job to the environment
permissions:
id-token: write # lets Atmos verify the environment via OIDC
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
Using Stores in Hooks
You can write values to stores using hooks:
components:
terraform:
vpc:
hooks:
store-outputs:
events:
- after.terraform.apply
command: store
name: prod/ssm
outputs:
vpc_id: .vpc_id
subnet_ids: .private_subnet_ids
This writes Terraform outputs to the configured store after apply completes. The output values starting with . reference Terraform output names.
Related
- External Stores - Using
!storefunction in stacks - Hooks - Writing to stores with hooks
- Terraform State - Alternative data sharing method