A beta program brief for invited engineering teams — what GRIT is, why it's faster, and how to get up and running on it in under ten minutes.
GitHub-hosted runners are convenient but slow. Self-hosting is fast but a maintenance disaster. Either way, every minute spent waiting on a green check is a minute a developer context-switches out of flow — and the cost shows up on the engineering velocity line, not the AWS bill.
Three numbers we hold ourselves to. Beta customers see them in their first week.
Sub-second cold starts on dedicated bare-metal compute. No noisy neighbors, no shared queues, no surprise capacity dips at 9:01am Monday.
See exactly where every second of every job goes. Per-step timings, cache hit rates, queue waits, regressions surfaced before your team feels them.
Concrete, ranked suggestions for your pipelines — caching opportunities, parallelisable steps, redundant work — opened as PRs you can merge or ignore.
Same actions, same secrets, same syntax, same logs. GRIT runners register against your repository the way any GitHub-compatible runner does — your workflow files only need to know the new label.
# .github/workflows/ci.ymljobs: test: runs-on: ubuntu-latest runs-on: grit-ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm ci && npm test
Install the GRIT GitHub App on your org. ~2 minutes.
Change runs-on on the workflows you want to accelerate.
Builds get faster. Insights show up. Costs drop.
No magic. Just deliberate engineering choices on every layer of the stack — and the right tradeoffs for CI workloads specifically.
Modern EPYC and Ryzen hosts with no virtualisation tax and no cloud-tenant contention. Your build gets the cores it asked for, every time.
Each job runs in a fresh, hardware-isolated microVM that boots in under a second. Strong isolation, near-zero startup penalty.
Docker pull-through and an npm registry mirror live on every host. The packages your build needs are already local — pulls become loopback reads.
The autoscaler keeps capacity ready before your webhook arrives. Queue waits trend toward zero — your developers don't feel them.
Every job runs in a fresh microVM that's destroyed at the end. Untrusted workflow code never shares a kernel with another job.
Per-step timings, cache hit rates, queue waits, runner health — all surfaced in the dashboard from the first job onward.
Same actions ecosystem, same secrets, same artifacts. No new YAML to learn. Migrate one workflow at a time.
Install the app, swap one label on your noisiest workflow, and watch the next push come back faster. We'll be in the Slack channel if anything looks off.