Post

Today, we're announcing our first hosted infrastructure product: pyx, a Python-native package registry. We think of pyx as an optimized backend for uv: it’s a package registry, but it also solves problems that go beyond the scope of a traditional "package registry".

pyx is now live with our early partners, including Ramp, Intercom, and fal. As we work towards GA, we're looking for more early users to help shape the future of Python infrastructure. Get in touch today 👇👇👇 astral.sh/pyx

With pyx, uv becomes even faster, more secure, and hardware-aware (PyTorch, CUDA, FlashAttention, etc. become first-class citizens). You can use pyx to host private packages (it's much faster than other private registries), or as a frontend to public sources like PyPI.

Much of the inspiration for pyx comes from the classes of problems we see in the uv issue tracker that we can't solve with a client alone -- but could solve with a server. For example...

"Why is it so hard to install PyTorch, or CUDA, or libraries like FlashAttention or DeepSpeed that build against PyTorch and CUDA?"

"Why is everyone on my team re-building the same packages over and over again on their machines?"

"Why did the latest setuptools release break our build? Can't we harden against that?"

With pyx, we can solve these problems. And for me, that's the most exciting thing about it. By providing our own end-to-end infrastructure we can solve _so_ many more problems for users that used to be out-of-scope.

From that perspective, pyx is just the first piece in a broader vision to build the Astral platform: our next-generation infrastructure for Python.

Our deep focus on Python enables us to build better Python infra than anything else out there; and integration with our open source tools enables us to build experiences that otherwise wouldn't be possible at all.

You won't need to use pyx to use uv, and you won't need to use uv to use pyx. But when used together, entire classes of problems disappear.