runs-on.com retweeted
New high: 5M+ runners across all @RunsOnRunsOn users. 8x to 16x cheaper than GitHub Actions on real builds.
Word of mouth is one of the highest driver of runs-on.com growth
runs-on.com retweeted
Replying to @crohr @RunsOnRunsOn
oh hey! we switched all our CI from GHA to RunsOn a few weeks ago. it Just Worked™ — thanks for an amazing product
EC2 spot instances are a very good fit for CI workloads, most of the time. runs-on.com/docs/costs/spot-…
runs-on.com retweeted
Heavy GitHub Actions bill? Have a look at our state of actions report to identify what's costing you most. I'm deep into it every day and I still discovered a few stragglers
CI has always been invisible and is supposed to "just work".
But not anymore.
Since agents are shipping a lot of code, invisibility becomes a real problem until that humongous bill hits.
This is why I built State of Actions.
It takes all the insights and usage metrics GitHub provides (and doesn't) and brings it together in one place so that the state of your CI is fully visible BEFORE that bill hits.
Our main goal with this tool has always been for a user to understand how their CI on Actions is doing without having to scramble around GitHub for answers.
It's been a really fun ride iterating over and over again as the models get better to make this the best experience possible for all kinds of users - from solo devs to enterprise.
So here it is, a fresher UI that helps you answer your burning questions on CI with clarity and ease:
- Where do my minutes go?
- How much does it actually cost?
- How much am I paying for failed jobs?
- What runs queue slower than others?
And much more.
There are core sections that give insights on Cost, Usage, Performance and Reliability and a table view to filter out the exact workflow or job you're looking for, with a further panel to drill down into them.
There's a global search bar ofc if you want to quickly jump to a specific repo, workflow, job or label.
Will keep refining this as we get more and more feedback, so give it a go and tell me whether this helps you grasp the state of your Actions in the way you hope or not!
And ofc its free: soa.runs-on.com
The @pydantic team switched Logfire's CI to RunsOn on Sept 1.
August, on GitHub, Depot and Ubicloud runners: $18.2k.
September, on RunsOn: $5.7k, license and every AWS cost included.
And they ran 31% more runner minutes in September. 🧵
Same GitHub Actions, same workflows. Jobs now run on fresh EC2 instances in their own AWS account: mostly Graviton, Spot wherever a retry is cheap, on-demand for the merge queue and releases.
Bill Easton's write-up:
pydantic.dev/articles/ai-oh-…
Along the way, they built a RunsOn integration in Logfire: dashboards for queue times, Spot interruptions, cost per job, and runner CPU and memory.
A few lines of Terraform:
runs-on.com/blog/runs-on-pyd…
Some CI data is too large or awkward for an archive cache. Linux Flex runners can mount a shared EFS filesystem directly at `/mnt/efs`.
runs-on.com/docs/runners/cap…
Disks? Where we're going, we don't need disks.
extras=tmpfs keeps a RunsOn runner's workspace and Docker data in RAM. PostHog's image build on 4 vCPU: 9m05s → 5m02s. GitHub's own runner takes 12m44s and costs 13 times as much.
runs-on.com/blog/tmpfs-githu…
Need a predictable egress IP for CI allow lists? RunsOn supports static egress through private subnets on Linux and Windows, with Flex and Fleet.
runs-on.com/docs/runners/cap…
RunsOn can give AI-assisted CI direct IAM access to Amazon Bedrock, or host GitHub Copilot's coding agent inside your AWS account.
runs-on.com/docs/runners/cap…
runs-on.com retweeted
Won't make the benchmarks any faster though - runs-on.com/benchmarks/
runs-on.com retweeted
You should really try full tmpfs (YOLO) mode on your CI runners. Some workflows fly with it!
Only possible if your provider actually lets you use high-memory instance types though... which means only RunsOn or your own bare-metal!
RunsOn runners support SSM and optional SSH access on Linux and Windows, with both Flex and Fleet.
runs-on.com/docs/runners/cap…
This is the kind of graph that simple benchmarks don't show: how stable test times are across runs of the same CI workflow.
runs-on.com retweeted
Some CI providers tell you they are 10x, 20x, 40x faster at building docker images than @github! They're lying.
They are still operating from data from 1+ years ago.
(runs-on.com is 2x faster and 85% cheaper)
Not all CI providers are made equal. Only RunsOn can give you reproducible builds. All other providers can switch the underlying hardware at any time.
Can you run GitHub CodeQL on RunsOn runners? Yes.
On Fleet, point CodeQL default setup at your fleet label (`runs-on/fleet=<name>/env=<env>`). No workflow file needed.
On Flex, use advanced setup with your usual RunsOn label.
Docs: runs-on.com/docs/runners/cap…















