install-action: a GitHub Action that installs developer tools from their releases

One action replaces a set of curl steps

install-action is a GitHub Action for installing development tools, mainly from GitHub Releases, and it is written in Rust with the primary language recorded for the repository being Rust.

The usage is short. To install the latest version of a tool:

- uses: taiki-e/install-action@v2
  with:
    tool: cargo-hack

And there is a shorthand form, for when you do not need to pin the versions of this action and the installed tool:

- uses: taiki-e/install-action@cargo-hack

The tool input takes a whitespace or comma separated list, so several tools in one step is a matter of the value rather than the action:

- uses: taiki-e/install-action@v2
  with:
    tool: cargo-hack,cargo-minimal-versions

You can also pass the list as a block scalar, which is easier to read once the list grows, and tool names can be separated with whitespaces including line, space and tab:

- uses: taiki-e/install-action@v2
  with:
    tool: |
      cargo-hack
      cargo-minimal-versions

The three inputs are the whole configuration surface. The tool input is required. The checksum input controls whether checksums are enabled, and it is strongly discouraged to disable it. The fallback input chooses what happens for a tool that is not in the manifest, and it takes none, cargo-binstall or cargo-install, defaulting to cargo-binstall.

Versions, components and the shorthand forms

The version syntax has three levels, and the README is explicit that the patch can be omitted, as can the minor version if the major version is 1 or greater.

A specific version is written with the @version syntax:

- uses: taiki-e/install-action@v2
  with:
    tool: [email protected]

and the abbreviated form pins only the major and minor:

- uses: taiki-e/install-action@v2
  with:
    tool: [email protected]

The component syntax is the other feature, and it is the reason the action is more than a version downloader. For some tools, additional components can be installed at the same time with the + syntax, so a Rust toolchain with a component and a target is one entry:

- uses: taiki-e/install-action@v2
  with:
    # Install rust stable with rustfmt component and wasm32-wasip1 target.
    tool: rust+rustfmt+wasm32-wasip1
    # When installing another rust version:
    # tool: rust@nightly + rustfmt + wasm32-wasip1

The comment on the second line shows the combination of a version and components, which is the form you need if you want a specific toolchain version with extra targets.

There is a separate, deliberate asymmetry between the two kinds of tag. The @v major tag on the action and the @tool name tag on the tool are both updated with each release, so they float. The tool version inside the with block can be pinned independently, and the action version can be pinned to a full semver tag, in which case the tool version is associated with the action version and is pinned too.

That last point is the one to internalise: pinning the action to a full version also freezes the tool version, and a cooldown applied to the action applies to the tools it installs.

The fallback decides what happens for an unknown tool

The supported tools list lives in TOOLS.md, and it holds the tools that are installed from manifests managed inside the action. If a tool that is not in the list is specified, the action uses cargo-binstall as a fallback.

If you want to be sure the fallback is not used, you set fallback: none, and the input documents the three possible values:

- uses: taiki-e/install-action@v2
  with:
    tool: cargo-hack
    # Possible values:
    # - none: disable all fallback options
    # - cargo-binstall (default): use cargo-binstall (includes "quickinstall" and "install from source")
    # - cargo-install: use `cargo install`
    fallback: none

So the default fallback is cargo-binstall, which covers both the quick install of a prebuilt binary and installing from source, and cargo-install is the alternative when you want the source build. There is one platform caveat: on platforms where cargo-binstall does not provide prebuilt binaries, the cargo-install fallback is used instead of the cargo-binstall one.

This is the mechanism that decides how much you trust the action's manifest. If a tool is in the list, you get the curated path with the checks described below. If it is not, you get whatever the fallback does, which is a different code path with a different supply chain profile. Turning the fallback off makes an unsupported tool a hard error rather than a silent downgrade.

Adding a tool to the list is a documented process with a development guide, and the repository has a manifests/ directory and a tools/ directory that hold the manifest data and the supporting tooling.

Checksums, attestations and the dependency cooldown

The Security section is long, and it is the most useful part of the README for anyone running this in a workflow that matters.

For tools installed from GitHub Releases, the action downloads the tool or its installer over HTTPS with tlsv1.2 or later, which the README considers basically the same level of security as the recommended installation of rustup. It then verifies SHA256 checksums for the downloaded files, which is enabled by default and can be disabled with the checksum input, though the README says strongly that you should not disable it.

On top of that it verifies artifact attestations or signatures if the tool publishes attestations or distributes signed archives. And the ordering matters: verification is done at the stage of getting the checksum, so disabling the checksum also disables the attestation and signature verification. That is a good design, because it means there is no way to accidentally keep half the verification.

Then there is the dependency cooldown, which is the most interesting idea in the document. When you install with the tool name shorthand, or with an omitted version, the tool version reflects upstream releases with a delay of one to a few days, as with other package managers that verify checksums or signatures. A delay of at least one day is known as a dependency cooldown and it is intended to mitigate the risk of supply chain attacks, and the specific period may be changed in the future. You can bypass the cooldown by specifying a version explicitly.

So the action deliberately slows down the arrival of new upstream versions, on the reasoning that if a release is compromised, a package manager that verifies checksums will catch it, but a workflow that installs the newest thing within minutes of it being pushed will not.

The action version tag also moves, so a cooldown on the action itself applies to the tools it installs, which is the reason to pin the full version if you want the whole thing frozen.

The token question and the tool-specific policies

There is one more security decision in the README that is easy to skim past, and it is about the token you hand to the fallback.

The default fallback, cargo-binstall, is often affected by GitHub's API rate limits, so the action passes the github.token to cargo-binstall. Disabling the cargo-binstall fallback prevents the token from being passed, which helps with security.

So there is a direct trade here. The fallback needs the token to work reliably against the API rate limits, and the token is also a credential you would rather not hand to a third party binary. Setting fallback: none is what the README points you at for the security-conscious case, and it is why the Supported tools section is referenced right there in the security discussion rather than only in the usage section.

The security guidance on installation methods covers the other ways of getting a tool into a runner, with links to the security documentation for rustup, for snap, and for cargo-binstall, so you can compare the guarantees across the routes rather than assuming the action is the weakest or the strongest link.

The overall design principle is consistent. The action checks what it can, it verifies signatures when they exist, it slows down new versions, and it gives you the switches to turn each of those off. The switches are the risk, and the README says so about the checksum one at least.

The implementation is a Rust workspace with generated manifests

The Cargo manifest shows a workspace with two members, tools/codegen and tools/manifest-schema, and a comment above the shared lints table saying it is shared by projects under github.com/taiki-e and is not intended for manual editing for the check-cfg entries.

That codegen member is the interesting part. The supported tools list is not a hand-maintained list of shell commands, it is generated from manifests, and the manifest-schema member is the schema those manifests are validated against. So adding a tool is a matter of writing a manifest entry rather than adding a special case to the action.

The lint configuration is thorough in a way that suggests a project with an eye on maintenance rather than a weekend hack. The workspace lints set deprecated_safe, improper_ctypes and its definitions, non_ascii_idents, rust_2018_idioms, single_use_lifetimes, unnameable_types, unreachable_pub and unsafe_op_in_unsafe_fn to warn. The clippy configuration sets all and pedantic to warn, which downgrades the deny-by-default lints, and then adds a set of specific ones including as_ptr_cast_mut, as_underscore, default_union_representation, inline_asm_x86_att_syntax, trailing_empty_array and transmute_undefined_repr, with several noisy ones explicitly allowed at priority 1 and a comment giving the reason for each.

The repository layout backs this up. There is action.yml for the action definition, main.sh for the entry point, a manifests/ directory, a tools/ directory, TOOLS.md for the supported list, DEVELOPMENT.md for adding a tool, and a CHANGELOG.md. The tooling is a mix of Rust for the action itself, shell for the entry script, and the usual Rust linter configuration files, including a deny.toml for cargo-deny, a .clippy.toml, a .cspell.json and a .taplo.toml for the TOML files.

The release history shows the action is released constantly, with v2.87.29 on 2026-10-16, v2.87.28 on 2026-10-12 and v2.87.27 on 2026-09-09, and the last push was on 2026-10-20.

Editorial conclusion

Adopt taiki-e/install-action if your workflow installs tools by hand with curl and unpacking, because it replaces that with a manifest-driven install, checksum verification and attestation checks in a few lines. Do not adopt it if you need an obscure tool that is not in the supported list and you are unwilling to rely on the cargo fallback, and think twice before disabling the checksum input, since verification of attestations and signatures happens at the same stage and is disabled with it. Before you pin a version, read the security section, because the @v major and @tool name tags move with each release while the full version tag freezes everything, including the tool version the action installs.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. taiki-e/install-action on GitHub