Experimental Features
Experimental features in Atmos are new capabilities on the path to becoming stable. They are under active development and being refined based on community feedback. While APIs may change, experimental features are intended to graduate to stable—removal would only occur in extreme circumstances.
What "Experimental" Means
Features marked as experimental:
- May not be fully functional - Some documented functionality may not yet be implemented
- Are under active development - Features are being refined and validated through community feedback
- May have breaking changes - APIs or behavior might change without following semantic versioning guarantees
- May not have undergone extensive QA - Testing coverage may be limited, and edge cases may not be fully addressed
- Are not recommended for critical production workflows - Use at your own risk until they graduate to stable
When the experimental annotation is removed, all documented functionality will be fully implemented and the feature will be considered stable.
Current Experimental Features
The following features are currently marked as experimental. This list is automatically generated from our roadmap.
- Atmos AI AssistantDocsAnnouncement
An intelligent assistant built directly into Atmos CLI with support for 7 AI providers, persistent sessions, tool execution, specialized agents, and IDE integration via MCP and LSP.
- Secrets ManagementDocsAnnouncement
Declare the secrets each component depends on and provision their values per environment across backends like 1Password, GitHub Actions, AWS Secrets Manager, and SOPS. Resolve them at runtime with the `!secret` YAML function.
- Source ProvisioningDocsAnnouncementPRD
Automatically fetch component sources on first use—no separate vendor step needed. Just reference and deploy.
- Toolchain ManagementDocsAnnouncement
Automatically install and manage the correct versions of Terraform, OpenTofu, Helmfile, and other tools based on component requirements.
- Zero-config AWS SSO identity managementAnnouncement
Automatic SSO identity provisioning without manual configuration—Atmos detects and configures SSO settings.
- Native Dev ContainersDocsAnnouncement
Native Dev Container support with automatic container lifecycle management—start, stop, attach, and exec.
- Automated Terraform backend provisioningDocsAnnouncement
Automatic backend.tf generation from stack configuration. Backends are defined once and inherited.
- Automatic toolchain installation and version management
Install and manage tool versions (Terraform, OpenTofu, Helmfile) based on component requirements.
- YAML key delimiter for dot notationDocsAnnouncement
Configurable key delimiter expands dotted YAML keys into nested maps in stack files. Quoted keys stay literal. Supports custom delimiters.
- Editions: date-pinned defaultsDocsAnnouncement
Every change to a previously shipped default is journaled with the date it changed — eleven entries reaching back to February 2025. A top-level `edition` setting in atmos.yaml (or `--edition`/`ATMOS_EDITION`) pins the project to a date anchor — "2026", "2026-01", or "2026-01-15", rounding to the end of the period like Rust editions — so defaults that changed after that date keep their pre-change values. Explicit configuration always wins, new features are unaffected, and `atmos list editions` / `atmos describe edition` show the journal and the effect of a pin. This release also flips several defaults for un-pinned projects: the default log level moves from Info to Warning, `describe component` shows provenance annotations by default, and `list stacks` / `list instances` default to tree format.
- `atmos list affected` to identify changes for targeted CI/CDDocsAnnouncement
Identify which stacks and components are affected by changes, enabling targeted CI/CD pipelines.
- Component workdir provisioningAnnouncement
Isolated working directories for each component instance with `atmos terraform workdir` commands to manage them—eliminating conflicts when multiple instances share the same component source.
- Terraform CLI config managementAnnouncementPRD
Declare Terraform/OpenTofu CLI configuration (.terraformrc / .tofurc) under components.terraform.rc. Atmos renders it and exposes it via TF_CLI_CONFIG_FILE and TOFU_CLI_CONFIG_FILE.
- Terraform registry cacheAnnouncementPRD
Transparently cache Terraform/OpenTofu providers and modules behind one flag (components.terraform.cache.enabled) via an ephemeral local network-mirror proxy. Includes atmos terraform cache list/stats/prune/delete.
- SBOM generation from vendor, OCI, and Terraform provenanceAnnouncement
New experimental `atmos sbom generate` renders CycloneDX and SPDX SBOMs from vendor lock receipts, OCI source digests, and Terraform provider/module evidence in one provenance graph. CI artifact upload is included.
- File-scoped localsDocsAnnouncement
Define local variables at the file level for DRY configuration—familiar to Terragrunt users.
- Imperative stack namesDocsAnnouncement
Simple stack naming with a direct name field instead of complex name templates.
- File generation (`generate` blocks)DocsAnnouncement
Generate files like backend.tf and provider.tf from stack configuration with inheritance support.
- Automatic provider cachingDocsAnnouncement
Cache Terraform providers across components to speed up init and reduce bandwidth.
- `atmos store` CRUD CLI + `type: store` workflow stepDocsAnnouncement
A CRUD CLI (set, get, delete, list) and a `type: store` workflow step give raw, undeclared read and write access to any configured store. Neither requires a `secrets.vars` declaration. The step closes the loop with the existing read-only `!store` and `!store.get` YAML functions. A workflow can write a value, such as an image tag, and a completely separate stack or component can read it back.
We Need Your Help
Experimental features rely on community feedback to mature into stable, production-ready capabilities. Your real-world testing and input are invaluable—you help us identify edge cases, improve usability, and prioritize what matters most.
Ways to contribute:
- Try experimental features - Use them in non-critical workflows and share what works and what doesn't
- Report issues - File bugs or unexpected behavior via GitHub Issues
- Share feedback - Discuss your experiences in GitHub Discussions
- Join the conversation - Connect with us on Slack for real-time discussions
Graduation Criteria
Experimental features graduate to stable when:
- All documented functionality is fully implemented
- The API has been validated through real-world usage
- Community feedback has been incorporated
- Breaking changes are no longer expected
Controlling Experimental Features
When you run an experimental command, Atmos displays a notification:
🧪 `toolchain` is an experimental feature. Learn more https://atmos.tools/experimental
You can control this behavior with the settings.experimental configuration in atmos.yaml:
settings:
# Control experimental feature handling
# Values: "silence", "disable", "warn" (default), "error"
experimental: warn
| Mode | Behavior |
|---|---|
silence | Run without any notification |
warn | Show notification, then continue (default) |
error | Show notification and exit with error |
disable | Block experimental commands entirely |
Or use the environment variable:
export ATMOS_EXPERIMENTAL=silence
For detailed configuration options, see Experimental Settings.
Help Us Prioritize
Is an experimental feature working really well for you? Let us know! Your feedback helps us prioritize which features to promote to stable.
