How AWS Powers Gradle's Open Source Build Tool
Table of Contents
Introduction
The Gradle Build Tool runs a lot of the world’s software. Millions of developers use it every day, and almost every Android app on your phone was built with it. So somebody, somewhere, is kicking off a Gradle build right now. And the next one. And a thousand more in the next minute.
For all of them, it has to be fast, and it has to be there.
That isn’t free. Behind the open source project sits a plugin portal serving hundreds of millions of downloads a month, a CI fleet running millions of tests, a performance lab watching for regressions, and the security tooling that guards a supply chain a lot of the industry depends on. All of it runs on AWS. Here’s how.
Downloading plugins #
The Gradle Plugin Portal at plugins.gradle.org is where the community publishes the plugins that extend Gradle.
Every plugin JAR it serves (thousands of them, downloaded around 200 million times a month) lives in Amazon S3.
That’s what lets us be the front door for the plugin ecosystem without running a fleet of file servers ourselves.
Building and testing Gradle itself #
Most of our AWS bill goes here. Every commit to Gradle triggers hundreds of separate builds and tens of thousands of tests across our supported operating systems and architectures.
That fleet runs on:
- Amazon EC2, with auto-scaling to match capacity to demand.
- Amazon EKS, which orchestrates our containerized Test Distribution agents.
- Amazon ECR, which stores the agent container images.
Keeping Gradle fast #
A build tool only earns trust if it stays fast. Every commit runs through our performance test suite, and the results land in Amazon RDS, where we compare against history and catch regressions before they reach users.
Securing the build #
Protecting a build tool means protecting a supply chain.
Our CI authenticates to AWS through AWS Identity and Access Management (IAM) with GitHub OIDC. That gives us keyless, short-lived credentials, and any secrets we still need are pulled on demand from AWS Secrets Manager and AWS Systems Manager Parameter Store. No static keys sitting around to leak.
For everything else, we lean on AWS security services as a layered defense:
- Amazon GuardDuty for threat detection.
- AWS Security Hub to centralize findings.
- AWS Config for compliance.
- Amazon Inspector for vulnerability scanning.
- AWS CloudTrail and Amazon CloudWatch for audit and observability.
- AWS Network Firewall, with VPC flow logs, at the perimeter.
These are the services our incident-response playbooks call out by name.
What changed when we moved CI to AWS #
For years we ran Gradle’s CI on dedicated servers. It worked, but it hurt in two specific ways.
Scaling was painful. The pool of machines was fixed, so a busy release window, or a flurry of commits landing at once, meant builds queued behind one another with no quick way to add capacity.
Management was manual too. Provisioning, patching, and keeping a fleet of physical machines consistent was slow, hands-on work that didn’t lend itself to automation.
Moving to AWS fixed both. With EC2 auto-scaling and EKS, capacity grows and shrinks with the load, so builds don’t wait for a free machine. And because we bake our build agents into machine images (AMIs), every node comes up identical, and we manage the fleet as code instead of by hand.
The security benefits showed up for free: threat detection, compliance, and vulnerability scanning that we would otherwise have had to build and run ourselves.
Thank you, AWS #
Serving the Plugin Portal worldwide, building and testing every commit, running a continuous performance lab, and protecting the whole supply chain isn’t cheap. Over the past year, AWS has given us $192K in credits, which covers most of our open source infrastructure bill.
That matters to us in three concrete ways.
First, it keeps the work open source. The Gradle Build Tool and the Plugin Portal stay free and reliable for everyone. Second, it frees up our team. Instead of chasing funding for infrastructure, we spend our time building the features the millions of developers who rely on Gradle actually want. Third, it makes Gradle better. An elastic, auto-scaling build fleet beats a fixed pool of servers, so builds finish faster, and the Plugin Portal stays up.
Without partners like AWS, Gradle wouldn’t be the project it is today.