Getting started
Onboard in minutes.
Speedforge does the migration for you. Install the GitHub App and it
opens the runs-on pull requests across your repositories —
you just review and merge. No pipeline rewrites, no internal
identifiers to wrangle.
The onboarding flow
From install to running on Speedforge is four steps, and Speedforge automates the work in the middle.
Install the GitHub App
Add the Speedforge App to your organization and choose which repositories it can see. Speedforge derives everything it needs — your org and installation — from the install event itself. You never enter an installation id, scale-set name, or any internal identifier.
Speedforge opens the migration PRs
Speedforge scans the workflows in your installed repositories and opens pull requests that switch GitHub-hosted labels to runs-on: speedforge. The migration touches only the runner label — your steps, caches, matrix builds, and secrets stay exactly as they are.
Review and merge when you're ready
The PRs land in your repos like any other change. Read the diff, run them on a branch first if you like, and merge on your schedule. You stay in control of every workflow that moves.
Ship
Your next run executes on a dedicated, isolated Speedforge runner — same logs, same Actions UI, same results. That's it.
Prefer to do it by hand? You can. Just change runs-on: ubuntu-latest to runs-on: speedforge in any workflow yourself — the automated PRs are a convenience, not a requirement.
What a migration PR changes
Exactly one line per job. Here is a typical diff:
# .github/workflows/ci.yml jobs: build: - runs-on: ubuntu-latest + runs-on: speedforge steps: - uses: actions/checkout@v4 - run: make test
Everything else — your steps, your actions/cache, your build matrix — is untouched. Workflows you don't want on Speedforge stay where they are.
How your runners are provisioned
When you install the App, Speedforge reconciles a dedicated environment for your org through GitOps — no manual cluster operations:
- Dedicated, isolated namespace. Your runners get their own namespace with network policy that denies cross-tenant traffic and blocks access to the cluster API and instance metadata.
- Ephemeral, non-privileged runners. Each job gets a fresh runner that is torn down afterward — clean state on every run.
- Autoscaling to zero. Runners spin up on demand and scale back to nothing when idle, so there is no standing fleet to babysit.
Try it free
New organizations start on a free trial — 30 days and roughly 100 CI minutes, no credit card required. Point a single workflow at speedforge, watch the run, and decide from real numbers.
FAQ
Do I have to rewrite my pipelines?
No. Speedforge speaks the standard GitHub Actions runner protocol. The only change is the runs-on label; your steps, caches, and matrix builds carry over unchanged.
Will Speedforge change my repos without asking?
No. The migration arrives as ordinary pull requests. Nothing moves to Speedforge until you review and merge them.
What permissions does the App need?
Only the repositories you select. To open the migration PRs it needs write access to contents, workflows, and pull requests on those repos — and nothing on repositories you don't choose.
How do I remove Speedforge?
Uninstall the GitHub App and revert the runs-on lines (or merge the revert). Speedforge tears down your dedicated environment automatically when the App is removed.
Can I mix Speedforge and GitHub-hosted runners?
Yes. Move the workflows you want and leave the rest. Migration is per-workflow and fully reversible.
Ready when you are.
Install the Speedforge App and let it open your migration PRs.
Install the Speedforge App