fishnet turns your own machine into a Stockfish node for Lichess

A volunteer computing cluster for one website's analysis button

Lichess offers a server side analysis feature, and the strength of that engine is bounded by how many machines the server owns. fishnet is the answer to that problem, and the repository description says it plainly: distributed Stockfish analysis for lichess.org. The model is volunteer computing, in the same family as Folding@home. You install a client, it asks the Lichess servers for work, it runs the engine locally, and it sends back results. The server keeps the analysis buttons on the site responsive without renting a data centre full of CPUs. The engine is Stockfish, which is where the name comes from, plus Fairy-Stockfish for chess variants. Both are present in the repository as the Stockfish/ and Fairy-Stockfish/ directories alongside a .gitmodules file, and the Cargo.toml excludes the compiled object files and the .nnue network files from the published package. Who it is for is straightforward. You need a spare machine, a personal fishnet key from lichess.org/get-fishnet, and a willingness to have the client occupy your CPU while it works. The project classifies itself under volunteer-computing topics, and the homepage for the key request is https://lichess.org/get-fishnet. What you get in return is nothing directly, which is worth saying plainly. You are donating cycles to a chess website.

Getting started: a key, a binary, and an update strategy

The installation has three steps and the first one is an account linked key. You request your personal fishnet key at https://lichess.org/get-fishnet, then install and run the client. For most people that means downloading the standalone binary for your platform from the latest release and running it.

# After download:
mv fishnet-x86_64-unknown-linux-musl fishnet
chmod +x fishnet
./fishnet --auto-update

Renaming the platform specific file to fishnet and marking it executable is all the setup there is. The client has a small set of commands worth knowing.

./fishnet configure              # Rerun config dialog
./fishnet systemd --auto-update  # Print a .service file
./fishnet --help                 # List commands and options

configure reruns the configuration dialog, systemd prints a .service file for a systemd host, and help lists everything else. There are also other installation methods documented in the repository: building from source, Docker, Kubernetes and OpenShift. The third step is the update strategy, and the README recommends running with --auto-update. You can also watch the repository on GitHub with a GitHub account and set it to release announcements only, so you hear about new versions without the client fetching them. The release history shows steady movement: v2.15.0 on 2026-10-07, v2.14.1 on 2026-09-05 and v2.14.0 on 2026-07-24.

Hardware requirements and the queue you land in

The requirements table is explicit about platforms. Linux on 64-bit Intel and AMD uses the x86_64-unknown-linux-musl build and on ARMv8 or Silicon the aarch64-unknown-linux-musl one. Windows is covered by x86_64-pc-windows-gnu.exe for Intel and AMD only, macOS has x86_64-apple-darwin and aarch64-apple-darwin, and FreeBSD is build from source with no ARM build listed. Beyond the platform, the README lists the runtime characteristics. It needs Linux or an operating system from around 2019 or later. It will max out the configured number of CPU cores, which is the line that matters most for a shared machine. It uses about 64 MiB of RAM per CPU core, and a small amount of disk space. Network communication is low bandwidth, with only outgoing HTTP requests, so probably no firewall configuration is required and IPv4 is not required either. The grading mechanism follows from the CPU speed. Almost all processors will be able to meet the requirement of about 2 meganodes in 6 seconds, and clients on the faster end are automatically assigned analysis jobs that have humans waiting for the result. That is the user queue, as opposed to the system queue for slower clients. So there is a genuine feedback loop between your hardware and the work you receive. A fast machine gets interactive requests, a slow one gets batch work in the background.

Why a healthy client sometimes sits idle

The FAQ has a question that every volunteer computing project eventually needs to answer: why is my client doing nothing. There are two documented reasons. Fishnet may estimate that another client would be able to complete the next batch more quickly, in which case handing the work to that client is simply better for the site. Or the client may have been configured to join the queue only if a backlog is building up, which is a setting you choose to keep your machine quiet when the site is not busy. The README frames standing by as useful rather than wasted. By staying available you still contribute to reliability by providing redundancy, and you contribute to the potential maximum throughput in case requests peak. That framing only works if you accept the system as it is. A client that never receives work is a client donating nothing, and there is no published leaderboard of contributors because the project says it would incentivize gaming the metrics. The other half of the operational picture is what happens when you stop. You can turn the client on and off at any time. By default it will try to finish any batches it has already started, and on immediate shutdown it tries to inform Lichess that the batches should be reassigned. If even that fails, Lichess reassigns them after a timeout, so a hard shutdown costs the site some duplicated work rather than lost work.

Containers and clusters: the Docker image and the deployment options

The Dockerfile in the repository shows what a containerised deployment looks like, and it is built around two stages with a hardened runtime.

FROM docker.io/niklasf/fishnet-builder:12.5.0 AS builder
ENV RUSTC_WRAPPER=/usr/bin/sccache
ENV SCCACHE_DIR=/sccache
ENV SCCACHE_CACHE_SIZE=250M
WORKDIR /fishnet
COPY . .
RUN --mount=type=cache,target=/sccache sccache --show-stats && cargo auditable build --release -vv && sccache --show-stats

FROM docker.io/alpine:3
RUN apk --no-cache add bash \
    && addgroup -S -g 10001 fishnet \
    && adduser -S -D -H \
        -u 10001 \
        -G fishnet \
        -s /sbin/nologin \
        fishnet
COPY --from=builder /fishnet/target/*-unknown-linux-musl/release/fishnet /fishnet
COPY scripts/docker-entrypoint.sh /docker-entrypoint.sh
USER 10001:10001
CMD ["/docker-entrypoint.sh"]

The builder stage uses sccache as the Rust compiler wrapper with a 250M cache directory, and it builds with cargo auditable rather than plain cargo, which is the same supply chain tool the README mentions. The runtime stage is Alpine with a dedicated non login user running as uid 10001, and the musl static binary is copied straight out of the builder. That combination of cargo auditable and an unprivileged user is the answer to the obvious objection about running unreviewed network code on your machine. The rest of the deployment surface is documented elsewhere in the repository, with install guides for Docker, Kubernetes and OpenShift, and the OpenShift guide has its own README under doc/openshift. For autoscaling, the README is blunt: there is currently no ready made solution. What exists is an API for monitoring the job queue status, described in the protocol documentation, so a cloud operator can build their own scaling logic on top.

Trust model, licence and the Rust toolchain floor

The security section of the README answers the question directly, with the answer To the best of our knowledge. All engine input is carefully validated. That covers the server side, and the client side is where the real risk sits. The README notes that you implicitly trust the authors and the GitHub and Amazon S3 infrastructure when running with --auto-update, and that you can mitigate this by running fishnet as an unprivileged user. Two dependency review tools are named: cargo-crev is used to review the trustworthiness of dependencies, and cargo-auditable is used to embed dependency metadata into the binaries. The SSLKEYFILE environment variable is also supported for inspecting traffic at runtime. The key mechanism is worth understanding because it explains both the trust model and the anti abuse story. The key allows Lichess to trace provided analysis back to your Lichess account, and a single key can run multiple instances. You do not need a key, nor permission, to run private instances, which is what makes local testing possible. The licence is GPLv3+, with the full text in LICENSE.txt and also available through the client itself with ./fishnet license. On the build side, Cargo.toml requires rust-version 1.95 and edition 2024, with the package version currently at 2.15.1-dev. The dependency list shows clap for the command line, reqwest and rustls for HTTP and TLS, shakmaty for chess position handling with the variant feature, tokio for the async runtime, semver for version checks, self-replace for the self update mechanism and zstd for compression. On x86_64 targets there is an extra dependency on raw-cpuid, which is how the client measures the CPU for its queue grading. The last push was on 2026-10-07, the same day as the v2.15.0 release, and the repository is not archived.

Editorial conclusion

Adopt fishnet if you run a personal machine or a home server with spare CPU cycles and you want the analysis feature on Lichess to work properly. Do not adopt it expecting GPU acceleration or a cloud deployment you can turn on with one click, because the README says the engine is CPU only and that no ready made autoscaling solution exists. Before pointing it at production work, read the requirement that the client maxes out the configured number of CPU cores and uses about 64 MiB of RAM per core, then decide how many cores to donate.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. lichess-org/fishnet on GitHub
3. Project website
4. README
5. Releases