When self-hosting GitHub Actions runners, understanding and managing rate limits across various services is crucial for maintaining efficient and uninterrupted CI/CD workflows. This guide provides an overview of rate limits for major services and some best practices to handle them effectively.
This blog post is also accompanied with a handy cheat-sheet which you can download here.
GitHub APIs
GitHub imposes several rate limits to ensure fair usage. These can cause issues when you are trying to pull information from GitHub using their APIs.
- API requests from self-hosted runners: 1,000 requests per hour across all actions within a repository.
- Primary rate limit for authenticated users: 5,000 requests per hour.
- Primary rate limit for GitHub App installations:
- Minimum 5,000 requests per hour (can go up to 12,500 depending on the number of repos and users).
- 15,000 requests per hour if the installation is on a GitHub Enterprise Cloud Organization.
- Primary rate limit for GITHUB_TOKEN in GitHub Actions: 1,000 requests per hour per repository. For GitHub Enterprise Cloud Accounts, the limit is 15,000 requests per hour per repo.
Secondary Rate Limits: Along with the primary limits above, GitHub also imposes secondary rate limits to limit concurrent calls from systems.
- No more than 100 concurrent requests allowed.
- No more than 900 read requests per minute or 180 write requests per minute to a single REST endpoint.
Cloud Providers (Provisioning Runners)
Keep these limits in mind when provisioning VMs as self-hosted runners on your preferred cloud provider.
AWS EC2
- Token Bucket algorithm: Maximum of 1,000 tokens, with a refill rate of 2 tokens per second.
Google Cloud Engine
- API Rate Limit: 1,500 requests per minute per region.
Microsoft Azure
- API Rate Limit: 1,200 writes per hour per subscription.
Hetzner Cloud
- API Rate Limit: 3600 requests per hour per project.
| These limits can be increased by contacting the respective cloud provider's support.
Docker Hub
Docker Hub enforces rate limits on container image pulls. As you can see, the limits are very less and are usually a major issue when using self-hosted runners.
- Anonymous users: 100 pulls per 6 hours per IP address.
- Authenticated users: 200 pulls per 6 hour period per account.
- Users with Paid Docker Subscription: Up to 5,000 pulls per day.
Read about how we dealt with this limitation in our runners in our blog post: Docker registry mirror setup
Image Registries
Amazon ECR
- Authenticated: 10 image pulls per second.
- Unauthenticated: 1 image pull per second.
Google Artifact Registry
- Rate Limits:
- 1,000 requests per second.
- 300 write requests per second.
Azure Container Registry
- Basic Tier:
- 1,000 read, 100 write operations per minute.
- Standard Tier
- 3000 read, 500 write operations per minute.
- Premium Tier:
- 10,000 read, 2000 write operations per minute.
| These limits can be increased by contacting the respective cloud provider's support.
Package Registries
RubyGems
- Rate Limit: 10 requests per second.
Best Practices
- Monitor Usage: Regularly check your usage against these quotas using tools provided by the respective cloud providers.
- Optimize API Calls: Reduce the frequency of API calls where possible, using caching and batch operations.
- Request Increases: If your usage patterns require higher limits, request quota increases for that service.
By managing these rate limits and optimizing your interactions with these services, you can ensure smooth and efficient operations for your self-hosted GitHub runners.
WarpBuild Runners
With WarpBuild, most of the rate limiting cases above (VM provisiong, GitHub APIs, DockerHub APIs) are automatically handled for you. WarpBuild provides performant runners for GitHub Actions for a fraction of the cost. Supercharge your builds and Go Warp! today.