I wanted to use WarpBuild for faster CI, but it only works for organization repos. Mine’s personal. So I needed another option.

GitHub Actions works fine, but I’m burning through minutes on E2E tests. Playwright builds a Next.js app, spins up browsers, clicks through checkout flows. The minutes add up. I started exploring alternatives and realized something: I’m already paying Fly.io to host the app. Why not run CI there too?

Working through this with Claude felt genuinely collaborative. We put together a Dockerfile with the GitHub Actions runner, an entrypoint script that registers with GitHub, and a fly.toml pointing at my repo. Deploy, set a token, and the runner appeared in my repo settings ready for work.

Then the real learning started.

The runner tried to auto-update itself mid-job, which corrupted its own binaries inside the container. We added --disableupdate. The Next.js build timed out on a small machine. We bumped to 8 cores. npm install crawled because nothing persisted between runs. We added a Fly volume for the cache. A Playwright test failed because it found a hidden file input instead of the visible title textbox. We fixed the selector.

Each problem had a solution, and working through them taught me more about containers, CI runners, and Fly.io than I would have learned from a tutorial. This is the kind of infrastructure work I usually dread, but having a capable partner made it genuinely interesting.

The result: CI that costs $2-5/month in actual compute, suspends when idle, and runs on machines I control. Not bad for an afternoon.