Pydantic runs on RunsOn

Pydantic moved its Logfire CI workflows to RunsOn on September 1, cutting monthly CI costs from $18,200 in August 2026 to $5,700 in September 2026 while runner minutes rose from 1,230,264 to 1,617,654. The company said its CI bill had climbed from $3,990 in June to $10,778 in July and $18,200 in August as the Logfire team merged 2,032 pull requests in the 30 days to August 30, versus 365 pull requests in the same period of 2025. RunsOn launches ephemeral EC2 runners in Pydantic's own AWS account while GitHub continues to orchestrate workflows, and the September figure includes the RunsOn license plus all AWS compute, EBS, S3 cache storage and data transfer costs.

Pydantic runs on RunsOn https://runs-on.com/ . We moved to RunsOn on September 1. It launches ephemeral EC2 runners for Logfire https://pydantic.dev/logfire 's GitHub Actions workflows in our AWS account. Logfire is built in our pydantic/platform repository. Previously, we used a mix of GitHub Actions, Depot, and Ubicloud for our CI infrastructure. Why did we make the move? Our CI bill rose from $3,990 in June to $10,778 in July, nearly three times April's spend. By August, it had reached $18,200. By August 30, the Logfire team had merged 2,032 pull requests that month. Over the same 30 days in 2025, a team of the same size merged 365 pull requests. Our CI costs were exploding as the team adopted AI and began shipping more than ever before. | Month | Total CI cost | Total runner minutes | |---|---|---| | April 2026 | $3,813 | — | | May 2026 | $3,665 | — | | June 2026 | $3,990 | — | | July 2026 | $10,778 | — | | August 2026 | $18,200 | 1,230,264 | | September 2026 | $5,700 | 1,617,654 | The main CI workflow in pydantic/platform ran 4,194 times in May, 6,669 times in June, 11,919 times in July, and 20,659 times through August 30. Growth continued after the move: runner minutes rose from 1,230,264 in August to 1,617,654 in September, while total CI cost fell to $5,700. We weren't delivering slop. We shipped real products, added important tests, improved browser coverage, and ran significantly more automated reviews. AI accelerated all of it. A repository that once merged hundreds of pull requests per month now merges thousands, with bots creating much of that activity and responding to the rest. RunsOn gave us a way to absorb that growth without slowing the team down. With RunsOn, GitHub still orchestrates every workflow, while fresh EC2 runners start in our AWS account and disappear when the job finishes. We did not have to replace GitHub's CI control plane or build our own runner platform to control the machines, networking, storage, and cost underneath it. Once RunsOn was installed in our AWS account and connected to GitHub, ordinary jobs mainly needed a different runner label and the RunsOn setup action. Container builds needed some additional cache and registry changes. GitHub Actions and managed runner services had let us reach this scale without operating a runner fleet. Above a million runner minutes per month, we wanted more control over which machines we paid for. RunsOn handles the runner lifecycle. We still manage our AWS account, runner catalog, capacity strategy, storage, cache policy, quotas, and telemetry. RunsOn pays for itself at 22 jobs per day https://runs-on.com/blog/runson-break-even/ , a threshold we were well past. Today, our catalog ranges from one-core ARM runners to 16-core image builders. Most Python, TypeScript, agentic, and control-plane jobs run on Graviton; x64 remains for container builds and tests that require it. Each preset contains several eligible EC2 families so the Spot allocator has more capacity pools to choose from. RunsOn's Magic Cache https://runs-on.com/docs/performance/caching/actions/ serves existing actions/cache calls close to the runners, while sticky EBS disks preserve expensive BuildKit state. We did not make every job Spot. Merge-queue validation, release publishing, deployments, and jobs with expensive restarts use On-Demand instances. Long, interruption-sensitive jobs use capacity-optimized Spot placement. Shorter jobs use price-capacity-optimized placement. The private deployment spans three availability zones, and a circuit breaker temporarily sends new jobs to On-Demand after a burst of interruptions. This sounds complex, but RunsOn does the heavy lifting. September was our first month on RunsOn. Our total CI cost was $5,700, down from $18,200 in August. That includes the RunsOn license and all AWS costs: compute, EBS, S3 cache storage, and data transfer. Three rules mattered more than any individual instance type: - Use Spot where retries are cheap. Keep the merge queue and release paths on On-Demand capacity. - Right-size against the critical path. The cheapest runner is the one that meets the workload's latency target at the lowest total cost. - Keep cache near the compute. Retain it only while it is likely to be reused. AI increased the amount we could deliver, and our CI bill grew with it. We did not ask the agents to stop. We changed where their builds and tests ran, then kept tuning the machines, caches, and capacity as the workload grew.