Migration

Every tool here is good at the job it was built for. Each page maps one of them against velodex: the equivalents table for what you run and configure today, the measured performance where the benchmark suite covers the tool, and the honest list of things velodex does not replace. If you want the decision matrix instead of the tour, start with when to use velodex.

• From devpi

  What devpi and velodex share, what devpi does that velodex does not, what velodex adds, and how to move across.

• From proxpi

  What proxpi and velodex share, where proxpi stays minimal, what velodex adds, and the one-line client change to move.

• From pypiserver

  What pypiserver and velodex share, why its fallback redirect is not a cache, what velodex adds, and how to move.

• From pypicloud

  What pypicloud and velodex share, the cloud backends it offers, what velodex adds, and how to move off an archived project.

• From simpleindex

  Route-per-project becomes virtual layers, and the redirects become a cache.

• From Artifactory or Nexus

  Keep them for the other ecosystems if you must; serve Python from one small binary with the modern protocols first.

• From cloud registries

  CodeArtifact, GitLab, Azure Artifacts, and Google Artifact Registry: what their Python support misses, and how velodex fronts or replaces them.

• From bandersnatch

  A mirror of everything versus a cache of what you use: when the full copy stops paying for its terabytes.

• From Pulp

  pulp_python covers the same ground with a platform's machinery; velodex is the same ground as one process.

• From static and legacy setups

  dumb-pypi, --find-links directories, pip2pi, nginx caches, and the other duct tape, mapped to one server.