Linux and WSL2
toryo installs on Linux, and on Windows through a WSL2 distro. There is no
desktop app there yet: this is the CLI, toryo and its fleet, installed by the
same one-line script macOS uses.
Read the honesty section at the bottom before you rely on any of this.
Install#
curl -fsSL https://raw.githubusercontent.com/ForceBuilders/toryo-releases/main/install.sh | sh
The script reads uname and picks one of toryo-<version>-linux-x64.tar.gz or
toryo-<version>-linux-arm64.tar.gz, unpacks it into ~/.toryo/bin, and runs
toryo setup. Inside a WSL2 distro it prints a line saying it detected WSL2 and
is installing the Linux build; that is the expected path, not a fallback.
To see which artifact your machine resolves to without downloading anything:
curl -fsSL https://raw.githubusercontent.com/ForceBuilders/toryo-releases/main/install.sh \
| TORYO_PRINT_ASSET=1 sh
Prerequisites#
Beyond the tools every platform needs (a coding agent, git, tmux, the GitHub
CLI, all of which toryo doctor names), the install itself wants these:
| Tool | Required | Why | If it is missing |
|---|---|---|---|
curl | yes | fetches the release | the installer stops immediately |
sha256sum or shasum | yes | checks the download against SHA256SUMS | the installer stops immediately |
minisign | no, but | checks who published SHA256SUMS | the installer warns and continues |
Most distributions ship sha256sum from coreutils and no shasum; either
satisfies the check.
minisign is strongly recommended and is not required. macOS releases carry
an Apple signature that toryo update verifies. Linux releases carry no
OS-level signature, so the authenticity gate is a minisign signature over
SHA256SUMS, made with a key that never travels with the download. install.sh
checks it when the tool is on your PATH and prints a loud warning block when it
is not. A checksum alone proves the download is intact, not that we published
it.
sudo apt install minisign # Debian, Ubuntu
brew install minisign # if you use Homebrew on Linux
toryo update always performs this check: it has the verifier compiled in and
needs nothing installed.
Services: systemd or your login shell#
toryo keeps foreman watch alive, and foreman watch keeps everything else
alive. What supervises that first process depends on your system:
- systemd available: a user unit at
~/.config/systemd/user/toryo-foreman-watch.service, enabled withsystemctl --user enable --now. It restarts on failure and survives logout if you have lingering enabled. - no systemd: a guarded start block in
~/.bashrc, which brings toryo up when you open a shell. It works out of the box, and it does not restart anything within a session.
WSL2 ships with systemd off by default. Turning it on is worth it:
# /etc/wsl.conf
[boot]
systemd=true
Then wsl --shutdown from Windows and reopen the distro. toryo doctor checks
for this and says so when it is off.
The database runs in-process#
Off macOS, toryo setup defaults the database runtime to pglite rather than
Docker, so there is no Docker Desktop dependency. It is real Postgres compiled
to WebAssembly, with the same schema and the same migrations. It serializes
queries through a single backend session, so a machine running many concurrent
jobs will feel it. Pass --runtime docker at setup if you would rather use
Docker; that choice is not reversible later without a dump and reload.
Keep everything off /mnt/c#
On WSL2, put both the repositories you work on and ~/.toryo inside the Linux
filesystem (/home/you/…). Git I/O across the Windows drive mount is slow
enough that per-run worktrees crawl, and toryo creates one per job. toryo doctor warns when it finds ~/.toryo on /mnt.
What has actually been tested#
Be clear about what these artifacts are.
The Windows and WSL2 path has never been validated on a real Windows box.
The platform probe, the supervisor renderers and the doctor checks are
unit-tested and were dry-run-verified on macOS; nobody has run wsl --install,
installed toryo inside a distro and watched a job execute.
The Linux binaries are cross-compiled on macOS and have not been smoke-tested on a Linux host. They are compiled, checksummed and signed by the same pipeline that ships the macOS release, and that is the whole of it: no test in this project has ever executed one.
So this is a supported install path in the sense that the installer exists, resolves the right artifact and verifies what it downloads. If it breaks on your machine, that is worth reporting rather than assuming you did something wrong. You may well be the first person to run it there.