Written by Jacob Coffee, Director of Engineering at the Python Software Foundation
Working on infrastructure at the Python Software Foundation (PSF) as the Director of Engineering is a broad job with many hats. Python turns up everywhere. It's in healthcare systems and government agencies, in research labs and classrooms, in one-person side projects and in infrastructure at companies with six-figure headcounts. Somebody is using it to analyze a genome right now and somebody else is using it to automate a spreadsheet they hate arranging by hand. That range has always been the interesting part of the PSF's work, and it's only broadened in the last couple of years as AI continues to pull people from many disciplines into writing Python.
At the PSF we support and maintain the infrastructure behind PyPI, Python.org, PyCon US, CPython, and a growing number of community services. The majority of the PSF's infrastructure runs on AWS, and nearly all of that bill is covered by credits from the AWS Open Source Credits Program.
The shape of it
PyPI takes over six billion requests a day and about thirteen billion counting file downloads. Package egress runs around 10 petabytes a day.
Almost none of that reaches AWS. Fastly serves it at the edge through their Fast Forward program at a hit ratio just under 99%, so only about one request in seventy makes it to origin. That caching is the core reason our AWS bill is not measured in the millions of dollars a year.
What does reach us is the part that is not cached, including things like user uploads, logins, and account management. That work runs on:
- Amazon EC2 for the application fleet, almost entirely Graviton at this point. We're huge fans of Arm-based hardware at the PSF!
- Amazon RDS for the Postgres database behind Warehouse, which is the application you're looking at when you're on pypi.org.
- Amazon OpenSearch Service for project search.
- Amazon S3 holds ~100 TB of package archives, plus the release history (that nobody ever wants to need).
- Amazon EKS, newly stood up, as the target for migrating the whole fleet.
What changed this year
Our AWS spend is up about 69% comparing July 2026 to July 2025, and 40% across the trailing twelve months. That's new.
For context on how new: last October, Ee Durbin, our former Director of Infrastructure, noted that PSF's AWS credit usage had grown 25% over eight years while daily requests went from millions to billions. Eight years of holding that line. 2026 is the first year it broke.
Some of it is simply more of everything. Compute, search, and load balancing all climbed from 30% to 80%, which is the profile of more people and machines using the service. There are certainly more of both. A lot more Python being written, a lot more agents installing packages on someone's behalf, and a lot more CI runs from all the projects those people and agents are creating. Package repositories were designed around the assumption that a human decides to run pip install some number of times a day. That assumption is well past its expiration.
What we do about it
At the PSF, we take the credits seriously, which means spending real engineering time on utilizing what we have in an optimal way so our usage doesn't increase. Being frugal with the credits entrusted to us is vital.
When a widely used GitHub Action makes requests it doesn't need to make, fixing the Action beats anything we can do on our side. A popular Action can quietly turn a cache hit into a fresh download from PyPI on every run, and that adds up fast across thousands of CI pipelines. astral-sh/setup-uv shipped exactly that kind of fix.
On the PSF side, the EKS migration is the big one. Once we're there, autoscaling lets capacity track demand instead of sitting provisioned for peak at 3 AM (San Francisco time) on a Sunday.
There's just one little (read: major) constraint: Ee left the PSF earlier this year, and I'm currently the only person here working full time on infrastructure. Every item on that list is real and every one is slower than it should be. The PSF is hiring, and that hiring is possible in part because we aren't spending the same money on servers.
That said, hiring has a ceiling set by funding, and the growing gap between the demand placed on PyPI relative to staff operating and securing the service represents a risk to Python packaging. There is a very large amount of the software industry that sits on top of our services. Feature development, a rising volume of security reports, and day to day maintenance are currently being carried by one and a half full-time employees and one full-time employee on PyPI support requests. If your company installs from PyPI, ask internally about what your organization would be willing to fund. That question can be worth much more coming from inside a company than from the PSF. If you are interested in securing a service agreement with PyPI, please fill out our survey.
What the funding actually bought
AWS has backed PyPI two different ways, and both are worth outlining.
A very exciting investment was made in 2023, when AWS became PyPI's inaugural Security Sponsor, putting $144,000 into creating the PyPI Safety & Security Engineer role. That role is now funded by Alpha-Omega, and it's the reason malware comes down off PyPI in hours instead of whenever a volunteer has a spare moment. This investment also followed a pattern AWS had already established, having helped fund the rewrite, internationalization, and 2FA support for PyPI.
The credits do something quieter. They hold the infrastructure bill near zero, which means the PSF's general fund goes to employees, PyCon US, and other operational costs instead of servers. That's what pays for support staff handling the account recovery and project ownership requests that arrive every single day, and what makes it possible to ship things like Trusted Publishing, digital attestations, and organization accounts, instead of just keeping the lights on.
PyPI is free to use and will stay free to use at reasonable levels. Core publishing and installing stay free, permanently. What we are doing is building out real benefits for Organization accounts, and looking at sensible rate limits for the heaviest consumers at the top of the curve.
Which is exactly why in-kind support isn't just a line item to us. A sponsor choosing not to renew would mean an emergency migration or tens of thousands of dollars a month, either of which comes straight out of the work above. AWS has renewed every year since 2018, and the predictability of that is worth as much as the amount. The same goes for Fastly, Google Cloud, Datadog, Sentry, Depot, and PagerDuty, who carry other parts of this mountain of infrastructure.
How you can help
Four things, in order of how much they matter:
- Cache your installs. If your CI pulls from PyPI on every run with a cold cache, you're a meaningful part of the graph. The PSF uses Docker cache mounts and pip's cache on our own builds, and npm and apt caching too, because it's faster for us and cheaper for everyone. Free package repositories aren't a limitless resource, and the fix is usually about six lines of config.
- Sign up for a PyPI Organization if your company publishes to PyPI. Recurring revenue from Organizations is the most sustainable funding base we have, and Community organizations remain free. Look forward to announcements about future features for PyPI organization accounts soon.
- Interested in a PyPI service agreement? Enhanced options like annual bulk seat purchases, higher project size limits, and prioritized support are available. The revenue helps fund the broader PyPI ecosystem while giving your organization benefits at scale. Fill out our service agreement interest survey and we'll follow up.
- Ask your infrastructure vendors for multi-year commitments with open source foundations. Annual renewal cycles carry real risk for projects like ours. The five-year agreement the PSF signed with Fastly in 2024 is a sustainable model, and we'd like more of them.
The open letter the PSF co-signed last year called this a critical inflection point rather than a crisis. A year on, with our first real break in eight years of flat infrastructure costs, that still reads about right.
A big thanks to Mila Zhou and the AWS Open Source team, who have made the credits process about as painless as an annual funding renewal can be, and to everyone at AWS who's kept this program going for so long. PyPI would look very different without it.
This blog was recently edited to more accurately reflect numbers presented and work done.
Facts Only
Jacob Coffee is the Director of Engineering at the Python Software Foundation (PSF).
PyPI receives over six billion requests and approximately thirteen billion file downloads daily.
Daily package egress is approximately 10 petabytes.
Fastly serves as the edge cache for PyPI with a hit ratio just under 99%.
PSF infrastructure utilizes Amazon EC2 (Graviton), RDS (Postgres), OpenSearch, S3, and EKS.
AWS spending increased 69% from July 2025 to July 2026 and 40% over the trailing twelve months.
AWS provided $144,000 in 2023 to create the PyPI Safety & Security Engineer role.
One full-time employee currently manages infrastructure; one full-time employee manages PyPI support requests.
The PSF signed a five-year agreement with Fastly in 2024.
PyPI core publishing and installing are free.
Executive Summary
The Python Software Foundation (PSF) manages critical infrastructure for the Python ecosystem, including PyPI, which handles over six billion daily requests and 10 petabytes of daily package egress. While Fastly caches nearly 99% of this traffic, the underlying AWS infrastructure—comprising EC2, RDS, OpenSearch, S3, and EKS—has seen a significant cost increase, with spending rising 69% between July 2025 and July 2026. This break in an eight-year trend of flat costs is attributed to increased usage by AI agents and CI pipelines, which bypass traditional human-centric installation patterns.
The PSF currently operates with severe staffing constraints, relying on a single full-time infrastructure engineer. To maintain service stability and security without diverting general funds from personnel to server costs, the PSF is pursuing a multi-pronged sustainability strategy. This includes migrating to EKS for better autoscaling, encouraging CI cache optimization, and introducing paid Organization accounts and service agreements for heavy corporate users. While core publishing and installing remain free, the PSF seeks more predictable, multi-year funding and infrastructure commitments to mitigate the risk posed by the growing gap between service demand and operational capacity.
Full Take
The strongest version of this narrative is a transparent plea for systemic sustainability. The PSF is highlighting a "tragedy of the commons" where the exponential growth of AI-driven automation—benefiting private industry—is placing an unsustainable burden on a non-profit's thin operational layer.
The narrative employs a subtle urgency, framing the current staffing level (one and a half employees for a global critical dependency) as a systemic risk. This is a calculated move to shift the conversation from "charity" to "risk management" for corporate stakeholders. By linking the stability of the software industry to the funding of a few specific roles, the PSF moves the goalposts from requesting donations to offering "service agreements" and "Organization accounts," effectively transitioning toward a "freemium" sustainability model for infrastructure.
Patterns detected: none
The root cause is the misalignment between the scale of modern automated consumption (CI/CD, AI agents) and the legacy funding models of open-source foundations. This echoes the broader trend of "corporate capture" of open source, where the value extracted by the industry far exceeds the value reinvested into the maintenance of the core utilities.
The implication is a potential shift in the nature of "free" open source. While the PSF asserts that core functions will remain free, the introduction of rate limits for "heaviest consumers" suggests a future where tiered access becomes the norm for critical digital infrastructure.
Bridge Questions:
1. If the PSF moves toward a tiered service model, does this create a "two-tier" ecosystem where smaller developers face more instability than corporate entities?
2. What alternative funding models exist for critical infrastructure that do not rely on the benevolence of a few cloud vendors?
Counterstrike Scan: A bad actor pushing this narrative would use "fear of collapse" to force an immediate, overpriced corporate subscription surge. The actual content is too focused on specific technical fixes (EKS migration, CI caching) and transparently lists current staffing to be a coordinated manipulation; it is a genuine operational SOS.