BerryBoxGitHub Actions on
fresh AMD machines.
Billed by the second.
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 list price per size, whether the VM runs on Spot or on-demand capacity. 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 new EC2 instance. When it finishes, the instance is terminated and its encrypted root disk is deleted. Nothing carries over to the next job.
- No keys on the machine
- Runner VMs accept no inbound connections and have no cloud role attached. They receive only a one-time runner config — never our AWS 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.
- Spending you control
- Credit is prepaid. Each job reserves its maximum runtime up front and releases what it didn’t use. Team spending limits pause new jobs.
- Capacity without surprise pricing
- We try Spot capacity first and fall back to on-demand. Your price per minute is the same either way.
Good to know before you switch
- Cold starts take tens of seconds; idle capacity scales to zero
- 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 provider 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?
No. Idle capacity scales to zero, so a cold start takes tens of seconds and can take longer when AWS capacity is scarce. That wait is free, and the Jobs page shows it 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.