BerryBoxGitHub Actions on
fresh Linux machines.
Billed by the second.
What every job gets
A clean machine per job.
Billed only while it runs.
One VM per job, then it’s gone
Each job gets a fresh, isolated runner. When the job ends, the runner and its encrypted disk are removed. Nothing carries over.
Billed by the second
Billing starts when your job runs. Queue time, VM startup and platform failures are free.
Docker ready on boot
Ubuntu 24.04 with Docker, Buildx and Compose preinstalled. Service containers work as on GitHub-hosted runners.
Run jobs in parallel
Run multiple jobs within your team’s concurrency limit. Track progress, runtime and cost for each job.
Prepaid, with limits
Top up from $20. Each job holds its maximum runtime and releases the rest. Team spending limits pause new jobs.
Migration
Three steps.
One line of YAML.
GitHub still schedules your workflow and shows the results. BerryBox supplies the machine: Ubuntu 24.04 with the official Actions runner, Docker, Buildx and Compose.
- 1
Connect GitHub
Sign in, install the GitHub App and choose the private repositories it can use.
- 2
Add credit and pick a size
Top up from $20 through Stripe, then enable a runner size for your team.
- 3
Change runs-on
Point a job at a BerryBox label. Jobs on other labels stay where they are.
name: cion: [push, pull_request] jobs: build: runs-on: berrybox-2vcpu-ubuntu-2404was ubuntu-latest steps: - uses: actions/checkout@v7 - uses: actions/setup-node@v7 with: node-version: 24 cache: npm - run: npm ci - run: npm test - run: docker build -t app .Everything else in the job keeps working as it does today:
- actions/checkout
- setup-* caches
- matrix builds
- service containers
- docker build
- secrets
- logs & checks
Not sure which jobs fit? Paste a workflow into the dashboard’s migration preview, or run berrybox migrate to see the patch first. Migration guide
Pricing
Price your builds
before you switch.
One clear price per runner size. Pay from prepaid credit; there’s no subscription or seat fee.
Security & operations
Every job runs alone.
Then its VM is deleted.
BerryBox is built by Strawberry Labs. Questions about isolation, billing or a stuck job reach the people who run the fleet.
Email the team- One job, one VM
- Each job gets a fresh, isolated runner. When it finishes, the runner and its encrypted disk are deleted. Nothing carries over to the next job.
- No keys on the machine
- Runners accept no inbound connections. They receive only the configuration needed for their job, never BerryBox credentials or the GitHub App key.
- GitHub stays in charge
- The official GitHub Actions runner executes your steps. Secrets, logs, checks and permissions work as they do today.
Good to know before you switch
- Startup can take tens of seconds; waiting is free
- Private repositories in GitHub organizations
- Pushes, schedules, manual runs, same-repo pull requests
- Linux x86-64, Ubuntu 24.04 only
- No fork pull requests or public repositories yet
- No Windows, macOS, ARM or GPU runners yet
Can I move one job at a time?
Yes. runs-on is set per job, so you can move a single job, compare it with your current runner, and keep the rest of the workflow where it is. Switching back is the same one-line change.
What exactly do you charge for?
The time a BerryBox job actually runs, measured by the second. Queue time, VM startup, skipped jobs and platform failures are not billed.
What happens when my credit runs low?
Before a job starts, BerryBox reserves enough credit for its maximum runtime. If the balance can’t cover that, new jobs wait instead of starting, and the dashboard shows why. Unused reservations are released when a job settles.
Are starts instant?
Startup can take tens of seconds, and demand can add to the wait. Waiting and startup are free, and the Jobs page shows the timing for every run.
Does caching work?
actions/cache and the cache options in setup-* actions use GitHub’s Actions cache, as they do on GitHub-hosted runners. Each VM starts with a clean disk, so local Docker layers aren’t kept between jobs.