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?"

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.

A "private registry" typically connotes security, compliance, etc. pyx gives you those things, but the ideas behind it are actually much bigger. pyx is about improving the developer experience of working with Python. Solving user problems with our own infrastructure.

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