Replace Aqua with the Atmos Toolchain
This reference explains how to replace the Aqua CLI with the Atmos toolchain. For the skill's decision guide, see ../SKILL.md. For the full toolchain feature reference, see atmos-toolchain.
Overview
Aqua is a tool-version manager and a CLI. Its config file is aqua.yaml. Atmos does not run the
Aqua CLI and does not read aqua.yaml. Atmos reuses only the Aqua registry data format: the
pkgs/ package listings the Aqua CLI also reads. The Atmos toolchain reimplements that registry
YAML schema with its own parser. It does not use the Aqua Go SDK. However, the toolchain supports
only a subset of the schema. It is not a full reimplementation.
Migration is mechanical for plain GitHub-release packages. Migration is not purely mechanical for packages that use the schema features listed in Functional Gaps below. Check each package against that table before you assume a 1:1 port.
Before / After
Before (aqua.yaml):
registries:- type: standardref: v4.245.0 # renovate: depName=aquaproj/aqua-registrypackages:- name: hashicorp/terraformversion: v1.9.8- name: kubernetes/kubectlversion: v1.28.0- name: jqlang/jqversion: v1.7.1
Aqua also generates aqua-checksums.json. This file records checksums for supply-chain
verification.
After (atmos.yaml + .tool-versions):
# atmos.yamltoolchain:use_lock_file: true # Explicit here; only required if you pin an edition before 2026-08-05.registries:- name: aquatype: aquasource: https://github.com/aquaproj/aqua-registry/pkgsref: v4.245.0priority: 10verification:checksums: when_availablesignatures: when_available
# .tool-versionshashicorp/terraform 1.9.8kubernetes/kubectl 1.28.0jqlang/jq 1.7.1
atmos toolchain install
Atmos also generates a lock file. Whether it does so automatically depends on the project's
edition. An unpinned project, or one anchored to an edition on or after 2026-08-05, gets
use_lock_file: true as its default. No configuration is needed. A project whose atmos.yaml
pins an edition dated before 2026-08-05 keeps the old default, false, and must set
toolchain.use_lock_file: true explicitly. By default, Atmos writes the lock file as
toolchain.lock.yaml under the toolchain install path. Set toolchain.lock_file to choose a
different path, for example a repo-relative path you can commit. This file records the resolved
version and checksum for each tool. It serves the same purpose as aqua-checksums.json.
Steps
- Mirror the registry. Map Aqua's
type: standardregistry with aref:pin to atoolchain.registriesentry oftype: aqua. Setsourcetohttps://github.com/aquaproj/aqua-registry/pkgs. Setrefto the same tag Aqua pinned. Atmos resolves the pin through the separatereffield, not through the URL path. Atmos acceptsrefonly whensourceis agithub.comURL. Ifaqua.yamlused a private or custom registry (including one declared with Aqua'stype: github_content), add it as a secondtype: aquaregistry entry. Use afile://or GitHubsourcefor this entry. Set itspriorityhigher than the public registry. Pinrefto a tag or commit SHA, not a branch. A branch such asmainis mutable and can change what installs without any change toatmos.yaml. - Convert each plain package. For a
packages:entry with no unusual fields, runatmos toolchain add owner/repo@version. You can also hand-write the.tool-versionsline. Both methods produce the same result. - Flag nonstandard packages. For any entry that uses a field or package type from the Functional Gaps table below, do not assume it ports automatically. Follow that row's workaround. Or leave the tool on Aqua temporarily until the team decides how to handle it.
- Replace
aqua-checksums.jsonwithtoolchain.verificationanduse_lock_file. Atmos verifies packages against checksum and signature metadata published by the registry itself. Setchecksumsandsignaturestowhen_available,required, ordisabled. Setuse_lock_file: trueto also record resolved versions and checksums intoolchain.lock.yaml, for the same reproducibilityaqua-checksums.jsonprovides. - Verify the migration. Run
atmos toolchain install, then runatmos toolchain list. Confirm the resolved versions match whataqua listreported before. If you added a custom registry, confirm Atmos actually used it. A registry entry that cannot resolve a tool fails silently: Atmos falls back to the built-in public registry instead of raising an error. For a tool that also exists publicly, this produces no visible symptom, just the wrong source. Runatmos toolchain install --reinstallwithlogs.level: Debugset inatmos.yaml, and confirm the log shows the tool resolved from your configured registry, not the public fallback.
Command Mapping
| aqua command | Atmos toolchain equivalent |
|---|---|
aqua install | atmos toolchain install |
aqua install github.com/hashicorp/terraform@v1.9.8 (ad hoc) | atmos toolchain install hashicorp/terraform@1.9.8 |
aqua g -i (generate + insert into aqua.yaml) | atmos toolchain add owner/repo@version (writes to .tool-versions) |
aqua list | atmos toolchain list |
aqua which terraform | atmos toolchain which terraform |
aqua info hashicorp/terraform | atmos toolchain info terraform (registry metadata for one tool) |
aqua exec -- terraform plan | atmos toolchain exec terraform@<version> -- plan (direct third-party use only). atmos terraform plan already resolves the toolchain automatically. Do not wrap it in atmos toolchain exec. |
aqua update-checksum | No separate command. toolchain.verification handles this automatically at install time. |
Shell Integration
Aqua uses the same shim-based method as asdf. Add export PATH="$(aqua root-dir)/bin:$PATH" to
~/.bashrc or ~/.zshrc. This puts Aqua's proxy directory on PATH. aqua-proxy resolves the
nearest aqua.yaml again on every invocation. As a result, plain terraform always resolves
correctly in any shell. This method needs no per-project setup.
The Atmos toolchain does not do this by default. Atmos resolves tools declared in
.tool-versions (the project-wide default) or dependencies.tools (a scoped override) and injects
them into PATH only for the duration of one atmos <subcommand> invocation. If you run plain
terraform in your shell, it will not use the Atmos-managed version unless you opt in to shell
integration. This is a supported mode, not a limitation. Use atmos toolchain env to export the
resolved PATH into your interactive shell:
Bash (add to ~/.bashrc):
eval "$(atmos toolchain env --format=bash)"
Zsh (add to ~/.zshrc):
eval "$(atmos toolchain env --format=bash)"
Atmos has no separate --format=zsh option. The bash format emits plain POSIX
export PATH=.... Zsh evaluates this output the same way.
Fish (add to ~/.config/fish/config.fish):
atmos toolchain env --format=fish | source
PowerShell (add to $PROFILE):
Invoke-Expression (atmos toolchain env --format powershell | Out-String)
Verify with which terraform (use Get-Command terraform on PowerShell). It must resolve under
the Atmos toolchain install directory, not Aqua's proxy directory.
Run atmos commands, including the shell integration commands above, from the directory that
contains atmos.yaml. If your shell is in a different directory, add --chdir /path/to/project
(short form -C /path/to/project) to the command.
Important: this method takes a static snapshot, not Aqua's dynamic per-directory resolution.
aqua-proxy resolves the nearest aqua.yaml again on every command. As a result, when you cd
into a different project, Aqua automatically switches versions. atmos toolchain env bakes the
resolved paths of the current directory into PATH one time, at eval time. It does not update
automatically when you cd. Re-run the eval line after you switch projects. Or use
atmos terraform ... instead of bare terraform when you work across multiple projects.
atmos terraform ... always resolves per invocation, regardless of shell state.
Atmos also has a direct equivalent to aqua-proxy: toolchain.proxies. Configure a proxy to
expose a toolchain tool under a command name that differs from the tool's own binary name. Atmos
creates a link in ${toolchain.install_path}/bin/proxy. That link re-invokes Atmos under the
configured command name. Atmos then resolves the tool, installs it if needed, and forwards the
arguments. atmos toolchain env puts this proxy directory on PATH when you configure at least
one proxy. Use this when a package name differs from the command name, for example a multicall
binary such as coreutils that must run under the name ls. You do not need a proxy for the
common case, where the tool's binary already has the name you want to type. In that case, the
direct PATH export above already provides it. The
atmos-toolchain skill does not yet cover toolchain.proxies in
depth; see Toolchain Proxies for the
full reference.
Functional Gaps
Atmos intentionally does not support the following Aqua schema features. Most of this list comes from the "Unsupported Aqua Features" list in atmos-toolchain.
| Aqua feature | Why it does not port directly | Workaround |
|---|---|---|
go_build package type | Not implemented. Atmos does not build tools from source. | Use a pre-built release if the project publishes one. Add it via a type: atmos inline registry. |
cargo package type | Not implemented. Atmos has no Cargo or crates.io installer. | No direct equivalent exists. Source the binary another way. |
go_install package type | Not implemented. Atmos does not run go install. | Use a pre-built release if the project publishes one. Add it via a type: atmos inline registry. |
aqua-policy.yaml / AQUA_POLICY_CONFIG | Atmos has no trust or policy-gating step. Aqua uses its policy file to control which configs and registries a user trusts, because some Aqua package types run arbitrary build or install scripts. Atmos supports only package types that download a pre-built asset directly, so it never runs an install script and needs no matching trust step. | None needed. Drop the policy file. |
version_filter | Atmos does not support this Aqua registry field. Aqua uses it to filter candidate GitHub tags before version resolution. | Pin an exact, already-known-good version in .tool-versions. |
version_expr / version_expr_prefix | Atmos does not support version-string manipulation through an expression. | Pin an exact version. |
go_version_file | Atmos does not support reading a version from a Go source file. | Pin the version explicitly in .tool-versions. |
import | Not needed. Atmos already lets you compose multiple registries by importing multiple atmos.yaml files through its own import: mechanism. A separate registry-level import field was not implemented. | Add multiple toolchain.registries entries directly. Or split them across atmos.yaml files and combine them with import:. |
command_aliases | Atmos does not support this Aqua field. | Use toolchain.proxies in atmos.yaml instead. toolchain.proxies creates a command-name link, the same role command_aliases plays in Aqua. Do not use toolchain.aliases for this. toolchain.aliases only maps a short tool name to an owner/repo registry entry for lookup. It does not change the command name a tool runs under. See the Shell Integration section above. |
tags | Not supported. | No equivalent exists. Atmos does not filter installs by tag. |
vars | Atmos does not support Aqua's per-package template variables. | Hard-code the value into the url template of a type: atmos inline registry entry. |
version_prefix is supported, not a gap. Atmos reads version_prefix directly from an Aqua
registry package definition. It applies the prefix automatically when it builds the download URL
and compares versions. A package that already ships from an Aqua registry needs no workaround. Add
version_prefix to a custom type: atmos inline registry entry when you define a tool with no
upstream Aqua registry entry.
github_archive and github_content are supported, not a gap. Atmos added these two Aqua
package types in PR #2416. Treat a package that
uses either type the same as any other Aqua package: convert it with
atmos toolchain add owner/repo@version.
Example
This mixed aqua.yaml file shows both cases:
packages:- name: hashicorp/terraform # plain GitHub release -- migrates cleanlyversion: v1.9.8- name: some-org/custom-tool # uses go_build -- needs manual portingversion: v2.1.0
hashicorp/terraform becomes atmos toolchain add hashicorp/terraform@1.9.8. For
some-org/custom-tool, add a type: atmos inline registry entry that points at a pre-built
release asset, if one exists. Otherwise, leave it out of scope for this migration pass.
Cross-Links
- atmos-toolchain SKILL.md: the Registries section and the "Unsupported Aqua Features" list. The Functional Gaps table above comes from this list.
- atmos-toolchain commands-reference.md:
covers
atmos toolchain add,registry list,registry search.