Launched this week
Skipbox
Cheap, fast GitHub Actions runners with unlimited minutes
61 followers
Cheap, fast GitHub Actions runners with unlimited minutes
61 followers
Skipbox runs your GitHub Actions jobs on your own Linux VM, kept between jobs, so Docker layers, package caches and installed tools are still there on the next run. Credentials, the workspace and every container are wiped after each job. A flat monthly price with unlimited minutes: $39 for 4 vCPU / 8 GB. Install the GitHub App and change one line to runs-on: skipbox. 7-day free trial, no card. Private repositories only.
Free Options
Launch Team
Framer AI AgentsDesign and publish professional sites with AI
Promoted
Hey Product Hunt 👋
Honestly, my GitHub Actions bills were getting out of hand, so I built my own runner: Skipbox ⚡
Cheap and blazing fast:
• 1/12 the cost of GitHub Actions at full use ($39/mo flat vs $500 for GitHub's 4-core runner)
• 1/8 the cost of Blacksmith
• 7× GitHub's cache space, and your Docker and npm caches stay warm between jobs
• 2× the CPU of GitHub's standard runner
• Unlimited minutes, so run CI all day
Switching over: install the GitHub App and change one runs-on line.
I'm really proud of how it turned out, and I'd love to hear what you think!
The $39 flat vs $500 comparison got my attention, but honestly the warm caches are what would make me switch — most of my CI time is just rebuilding Docker layers and reinstalling dependencies. I like that credentials, the workspace, and containers are wiped after each job while the caches persist; that's the tradeoff I want. Curious: if a job needs a truly clean machine, is there a way to opt that run out of the warm state, or is persistence always on?
@jcbuilds Thanks JC! That's exactly the tradeoff we were going for.
Not per job yet. Today it's a switch for the whole org: turn on "Clean every job" in Plans and billing, and every job gets a brand-new VM that's deleted with its disk when the job ends. If you just want a clean slate once, there's a "Reset machine" button. It rebuilds your warm machine from the image, so the caches start over.
Jobs from fork PRs always run on a fresh VM, whatever the setting.
Would a per-job opt-out (say, a separate runs-on label) cover your case?
Congrats on your launch! Any plans to bring these runners to other git providers?
@mdshack Thanks Micah! For now it's GitHub Actions only. Which provider are you on? If enough people ask for the same one, it'll move up the list.
with passwordless sudo and the docker layers carried over, what stops a job on a feature branch from poisoning what the next release build on main pulls from cache
@bbueno The warm machine is shared by all of your org's jobs, and It's the same trust model as a self-hosted runner you run yourself.
What you can do about it.
- Turn on "Clean every job" (Plans and billing). Every job then gets a brand-new VM, deleted with its disk afterwards, so nothing carries over. You lose the warm caches.
- Or keep the cache for everyday CI and build releases with `docker build --pull --no-cache`.
Fork PRs never touch the warm machine. they always get a fresh VM, and one that lands on the warm machine anyway fails before its steps run.
Another org's jobs never run on your machine.