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:

ToolRequiredWhyIf it is missing
curlyesfetches the releasethe installer stops immediately
sha256sum or shasumyeschecks the download against SHA256SUMSthe installer stops immediately
minisignno, butchecks who published SHA256SUMSthe 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 with systemctl --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.