Qlty CLI: One Rust Binary for Linting, Formatting and Security Scanning Across 40+ Languages

What Qlty CLI solves for polyglot repositories

A repository with Go, TypeScript and Terraform in it normally means three or four separate quality tools, each with its own config file, its own CI step and its own output format. Qlty CLI collapses that into one binary that speaks to 70+ static analysis tools across 40+ languages and technologies, and reports through a single interface. The README lists the categories it covers: linting, auto-formatting, maintainability, security scanning, code coverage and quality metrics. The intended user is a team that has outgrown one-language tooling but does not want to maintain a hand-rolled orchestration layer. Configuration is deliberately Git-aware, so the tool can focus on issues introduced by a branch rather than the whole history of a file, which is the difference between a check that runs in seconds and one nobody waits for.

How Qlty works: plugins, config as code and caching

The architecture is a Rust workspace, visible in Cargo.toml, where the crates are split by responsibility: qlty-analysis, qlty-check, qlty-config, qlty-coverage, qlty-formats, qlty-plugins, qlty-smells and qlty-types among others. The CLI is the front end; the plugins directory and qlty-plugins crate are what actually wrap the external tools. Configuration lives in .qlty/qlty.toml inside the repository, so the set of enabled plugins is version controlled alongside the code it analyses. qlty init generates a starting file based on the languages it detects. The README attributes the speed to caching and concurrency, and the Dockerfile shows the binary is built with cargo-chef so dependency compilation is cached across builds. That tells you where the performance budget goes: parallel execution of native tools plus a cache layer, not a container per linter.

Installing Qlty CLI on macOS, Linux and Windows

The README gives installer scripts for the native binaries. On macOS or Linux the command pipes the installer into bash; on Windows it uses PowerShell. These install native binaries, not a package manager entry, so there is no version pinning in the command itself and you should check the release you get.

# Install on MacOS or Linux
curl https://qlty.sh | bash

# Install on Windows
powershell -c "iwr https://qlty.sh | iex"

A Docker image is also published on GitHub Container Registry, but the README is explicit that the CLI does not use Docker to run linters. The image exists for people who prefer to run the CLI itself as a container. The README's own example of that usage is:

docker run --rm -it -v "$(pwd):/app" qltysh/qlty metrics --all

Once the binary is on your PATH, change into a Git repository and initialise it. The README shows exactly this two-step sequence, and qlty init writes the .qlty/qlty.toml file you then edit.

cd my_repo/
qlty init

First real use: sampling issues, formatting and smells

After init, the README's usage table is the shortest path to a useful result. qlty check --sample=5 prints a sample of lint issues rather than the full list, which is the sane way to see what the generated config actually turned on before you commit to it in CI. qlty fmt --all auto-formats the codebase, and because it runs the formatters natively it will rewrite files in place, so run it on a clean working tree. For maintainability, qlty smells --all scans for code smells such as duplication. Metrics are available too, and the README's example sorts by complexity with a depth limit, which is the form you want when you are looking for the worst offenders rather than a full inventory.

qlty check --sample=5
qlty fmt --all
qlty smells --all
qlty metrics --max-depth=2 --sort complexity --all

Where Qlty CLI is the wrong tool

The licence is the first constraint. The repository metadata reports NOASSERTION and the README describes the project as Fair Source with delayed open source publication. That is not an OSI-approved licence, and the README does not spell out the delay period or what happens to a fork during it. If your organisation has a policy against non-OSI licences, this is a stop, not a discussion. The second constraint is Docker. The README states plainly that the CLI does not use Docker to run linters and achieves performance by running them natively. Teams whose CI is built around containerised lint steps, or whose build hosts forbid executing downloaded binaries, will find that design works against them. Third, the README does not document rollback or how to revert a qlty fmt --all run, so treat formatting as a change to review like any other. Finally, if your repository is single-language and already well served by that language's native toolchain, the plugin layer adds a dependency without adding coverage.

Qlty CLI compared with running each linter directly

The real alternative is not another universal linter so much as the status quo: install each tool yourself, wire each one into CI, and merge the outputs. That approach has one clear advantage, which is that you control the exact version and invocation of every tool, and you can upgrade one without touching the others. Qlty takes the opposite position: the versions and invocations are owned by the plugin layer, and you get consistency and a single config in exchange for that control. The trade-off is visible in the repository layout, where qlty-plugins and the plugins directory mediate every external tool. For a polyglot repository this is usually the right trade, because the alternative is a CI file that nobody wants to edit. For a team that already has a tuned per-language setup, migrating means giving up that tuning unless the plugin exposes the same options, and the README does not enumerate which tool flags pass through.

Maintenance, releases and what the licence means in practice

The last push to the default branch was on 2026-09-23, and the most recent releases are v0.645.0 on 2026-09-23, v0.644.0 on 2026-08-28 and v0.643.0 on 2026-08-22. The version in Cargo.toml matches the release tag, so the workspace version and the release are kept in step. That cadence matters for upgrade cost: if you pin a version, expect frequent releases and check CHANGELOG.md between them. The repository ships a Makefile.toml and a Dockerfile, and CONTRIBUTING.md and SECURITY.md are present at the top level, so the project documents how to build and report issues. On licensing, the README says the CLI is completely free for all use including commercial projects with no limits on contributors, while also describing the project as Fair Source with delayed open source publication. Those two statements are about different things: free to use, and not immediately open source. Read LICENSE.md before you depend on it, and if your legal team needs an OSI licence, this is not one.

Editorial conclusion

Qlty CLI suits polyglot teams that want one lint, format and security command instead of a per-language toolchain, and it is free for commercial projects with no contributor limit. It is the wrong choice if you need an OSI-approved licence or if you must run linters inside Docker, since the README states Docker is not used to run linters. Before adopting it, run qlty init in a branch and inspect the generated .qlty/qlty.toml to confirm it enables only the plugins you want, then check LICENSE.md for the delayed open source publication terms.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. qltysh/qlty on GitHub
4. README
5. Releases