How lychee Is Installed and Distributed

Updated

lychee is distributed as a single static binary, which is the core reason its install and update process stays simple: you obtain one executable and run it, rather than resolving a dependency tree first. That makes it a reasonable fit if you want a lightweight link checker for docs, sites, or codebases without adding a runtime to your environment. The trade-off is that "simple" depends on how you prefer to get binaries — package manager, direct download, or a build from source — and the documentation's own framing is that installation and updates are "a breeze" precisely because everything ships in that one file.

What "single static binary" means in practice

A static binary bundles what the program needs into the executable itself. For lychee, the documented consequence is:

  • No complex dependency setup. You are not installing a language runtime or a set of shared libraries as a prerequisite to running the tool.
  • One artifact to manage. Installing means placing the binary somewhere on your PATH; updating means replacing that file with a newer one.
  • Portable across environments. The same artifact approach is what lets lychee run the same way on a developer machine and inside a CI runner.

This is the mechanism behind the "lightweight deployment" appeal: fewer moving parts means fewer places for an install to fail.

Ways to get lychee

The documentation presents the static binary as the distribution model and points to GitHub as the place to obtain it. In practice, that leaves you with a small set of routes, and the right one depends on your constraints:

Route Best when What you manage
Package manager Your OS or ecosystem already has lychee packaged Updates come through the same upgrade command as your other tools
Direct binary download You want the exact version, or you're pinning in CI You fetch and replace the file yourself
Build from source You need a custom build or a platform without a prebuilt binary You need a Rust toolchain and a build step

If your goal is simply "install it and move on," the package manager route gives you the least ongoing effort because updates ride along with your normal system upgrades. If your goal is reproducibility — the same lychee version on every machine and every CI run — downloading a specific binary and pinning it is the more controllable choice.

Updating

Because the distribution unit is a single file, updating is conceptually the same operation as installing: get the newer binary and put it where the old one was. Two practical notes follow from that:

  • Version pinning is easy, and so is drifting. If you install via a package manager, you may get a newer version than your CI uses. If you pin a binary in CI, you'll stay on that version until you deliberately bump it.
  • Check the version after updating. Running the tool's version flag confirms which binary is actually on your PATH, which matters when an old copy is shadowed by a newer one in a different directory.

Why this matters for CI/CD and large projects

The install model connects directly to how lychee is meant to be used. The documentation highlights async execution for speed on large projects and structured JSON output for CI/CD integration. A static binary supports both: a CI job can fetch one artifact, run it against a large Markdown or HTML corpus, and parse JSON results — without a setup phase that installs a runtime or resolves dependencies on every run. For a large project, that setup phase is often the slowest and most fragile part of a link-checking job, so removing it is the real benefit.

Common friction points

  • PATH and shadowing. After installing, if the command isn't found or runs an unexpected version, the binary likely isn't on PATH or an older copy is taking precedence.
  • Platform availability. Prebuilt binaries cover common platforms; an unusual architecture may push you toward building from source, which reintroduces a toolchain requirement.
  • Assuming "no dependencies" means "no configuration." The binary needs no runtime, but you still decide what to check and how results are reported — that's configuration, not installation.

If you want the lightest possible setup and don't need a specific version, use your package manager. If you need identical behavior across machines and pipelines, download and pin the binary. If neither prebuilt route fits your platform, build from source and accept the toolchain as the cost.