Review a pull request by booting it | Farid Zakaria’s Blog

Skip to content

Farid Zakaria

2026-09-09
·
4 min read

Review a pull request by booting it

tl;dr; trynix-preview is a GitHub action that comments a link on a pull request which lets you boot the PR’s build in the browser using https://trynix.dev. No servers, just browsers.

I ended my earlier trynix post with a list of ideas I think we could accomplish now that we can boot arbitrary /nix/store paths in the browser. The most obvious one was to let a reviewer boot a pull request’s build in the browser for testing, validation and feedback.
That is now real. 🤯
A demo is worth a 1000 words: here is a pull request (PR#31) against my sqlelf project, from a fork, with the comment our action left on it:

Click the link and a Linux machine boots in your tab with that PR’s sqlelf on PATH.
You did not clone anything, you did not build anything. No servers, no SSH, no VPN, no Docker, no VM, no cloud. Just a browser and a link. 😈
§Gimme. Gimme. Gimme.
As with any GitHub action, it’s just a few lines to add to your workflow.
The caveat is that you must have built and cached the path already, so the action can link to it. The action does not build or cache anything.
# Setup Cachix as our Nix cache.
- uses: cachix/cachix-action@v17
with:
name: sqlelf
authToken: $
# We build the pull request's code and push it to the cache, so the action can link to it.
- run: nix build .#default
- uses: fzakaria/trynix@v1
with:
cache: https://sqlelf.cachix.org
publicKey: sqlelf.cachix.org-1:MLnjolA9AsKscTOJKDSA+ZAcgIK8BwZA574j4+Cs2bg=
# You can have multiple attrs if you want to boot more than one path.
attrs: .#default

The action publishes and builds nothing. Whatever already fills your cache keeps doing it, and the action’s whole job is to simply provide the store paths via nix eval and hand the cache’s URL and public key to the browser.
It is not Nix cache provider specific, but I do recommend Cachix because it is free for open source up to 5GiB.11You should definitely sign up for Cachix but you can test this out without it since the free tier is very generous. 
You can checkout my trynix.yaml workflow for the full example. You have to set allow-unsafe-pr-checkout: true in the actions/checkout step because the workflow runs on a fork’s pull request, and that has security implications.22I recommend a private segregated cache for pull request builds, so that a fork cannot push to your main cache. 
If that is not your cup of tea, there is a version where a maintainer types /trynix on the pull request which kicks off the workflow.
In either case, the workflow runs on the default branch and checks out the pull request’s code, so a fork cannot edit the workflow that builds it.
§Game over?
Did I just upend all CI products by easily letting reviewers boot a PR?
Unfortunately, no. 🥲
The performance for large binaries is pretty bad. Even with many of the improvements I AI-assisted into the engine, large binaries can still take 1-2 minutes to execute.33I added a benchmark page, https://trynix.dev/bench/, to the site with a lot of rich data on boot and run times for various applications. 
Nevertheless, this is still a pretty amazing workflow and showcases the power of Nix.
Maybe as we get closer to AGI, our AI overlords will be able to optimize the engine to execute large binaries in a few seconds, but for now, the action is best suited for small to medium-sized binaries.

Improve this pageEdit @ 550c3ab

·
Text is CC BY-SA
·

RSS

/nix/store/m4qxd9r5y0v7syl8pl9xfjrhzz4ccczi-fzakaria.com

The trynix-preview GitHub action introduces a method for allowing reviewers to boot a pull request's build directly in a web browser via https://trynix.dev, eliminating the need for managing separate servers, SSH, VPNs, Docker, VMs, or cloud infrastructure. This capability stems from the ability to expose arbitrary /nix/store paths in the browser, which is demonstrated by allowing a Linux machine to boot into a tab showing the pull request's software on PATH without any traditional cloning or building steps.

The mechanism requires that the necessary build and caching steps are already completed before the action can link to the artifacts. The action itself does not perform any building or caching; its function is merely to provide the necessary store paths by referencing a shared cache URL and public key. The author recommends using Cachix as the cache provider due to its open-source nature, although testing is possible without it since the free tier is generous. For security and workflow integrity, it is advised to set allow-unsafe-pr-checkout to true in the actions step, as the workflow runs on forks, and maintaining a private segregated cache is recommended to prevent forks from pushing to the main cache. Alternatively, the workflow can be triggered by a maintainer typing /trynix on the pull request.

The overall workflow involves building the pull request code, pushing the result to a cache, and then using the trynix action to surface these store paths for browser execution. While this development showcases the extensive power of Nix workflows, the system currently faces performance limitations when executing large binaries. Even with recent improvements, large binaries can still require one to two minutes to execute. To address this, the author added a benchmark page to the site detailing boot and run times for various applications. Nevertheless, the action remains an amazing demonstration of Nix's power, but it is currently best suited for small to medium-sized binaries, with the expectation that future advancements in optimization may allow for faster execution of larger binaries.