PyVRP: a vehicle routing solver with an open core and a commercial tier

The open core stops at a specific line

PyVRP is described as an open-source, state-of-the-art vehicle routing problem solver, developed by Applied Routing, and the feature list in the README is written in two clearly separated tiers. The unmarked bullets are what the open package supports: pickups and deliveries covering the capacitated VRP, the VRP with simultaneous pickup and delivery, VRP with backhaul and the pickup and delivery VRP; vehicles of different capacities, costs, shift durations, routing profiles, and maximum distance and duration constraints; time windows, client service durations and release times; multiple depots; reloading along routes at different reload depots; optional clients with prizes for visiting; and client groups imposing additional restrictions on multiple clients jointly. Four bullets carry an [Enterprise] marker: automatic break planning for EU and US hours-of-service regulations, vehicle-client and client-client compatibility constraints and sequencing relations, fairness constraints like load and shift duration balancing, and soft clustering to encourage geographically compact routes. That boundary is drawn in the documentation rather than hidden in a price list, which is unusual and useful.

What the modelling interface actually covers

The tutorials tell you how much of the VRP literature the package has absorbed, and the list of notebooks is more informative than a feature matrix. There is a quickstart notebook that introduces PyVRP's modelling interface, which the README calls a great way to get started. Then each constraint family has its own tutorial: load and vehicle capacities covering client pickups, deliveries and multiple load dimensions; time and duration constraints covering time windows, service durations, release times, shifts and overtime; profiles covering different distances and durations for different vehicle types, plus modelling access restrictions; optional clients using rewards to visit them; mutually exclusive groups for modelling alternative services; reloading of vehicles at depots during routes; and shipments for paired pickup and delivery. The vocabulary is precise throughout, which suggests the authors came from the operations research side rather than building a routing SDK from a general programming background, and the multiple load dimensions item in particular goes beyond what a textbook capacitated VRP covers.

The algorithm is an iterated local search, and the docs say so

For anyone interested in the underlying algorithm, the README points to a page with a high-level description of the iterated local search algorithm, and separately to a notebook containing an implementation of the solve method using PyVRP's components. That second link is the interesting one for an engineer, because it means the solver is assembled from parts that the documentation exposes rather than being a sealed binary you call. The repository layout backs this up. There is a pyvrp directory for the package, a tests directory, a docs directory, a notebooks directory, a benchmarks directory and an instances directory, alongside a meson.build file, buildtools and subprojects directories, a .clang-format file and a gcovr configuration. A C++ toolchain in the middle of a Python project, with meson, build tools and subprojects for dependencies, is a strong signal about how the performance-critical parts are compiled and shipped to the Python layer.

Installing the package and running the command line

PyVRP is available on the Python package index as pyvrp and is installed the usual way:

pip install pyvrp

The package manifest adds a console script, pyvrp = pyvrp.cli:main, so a command line entry point ships with the library. The runtime dependencies are numpy at 1.26.0 or later, matplotlib at 2.2.0 or later, vrplib at 1.4.0 or later and tqdm, which tells you two things about the intended workflow. The vrplib dependency points at the standard vehicle routing instance libraries, so loading a benchmark instance is a normal part of using the package rather than something you assemble yourself. The matplotlib dependency suggests plotting is part of the standard loop, which is consistent with a solver whose output is a set of routes that someone has to look at. The manifest also declares requires-python of 3.12 or later, with classifiers for 3.12 through 3.15, and a build dependency group requiring meson and ninja, so a source install pulls in a C++ build.

Two version lines running at once

Here is a detail that will bite anyone pinning a dependency. The tagged releases are v0.14.1 on 2026-10-16, v0.14.0 on 2026-08-20 and v0.13.4 on 2026-05-20, and the last push to the repository was on 2026-10-17. But the package manifest in the repository declares version 1.0.0a0, with the classifiers listing Development Status as Production/Stable. So the source tree has already moved to a 1.0.0 alpha while the newest published tag is still 0.14.1. Whether the alpha is on PyPI is not something the README says, and that is exactly the kind of thing to check before depending on it. The 0.x to 1.x transition is also where breaking API changes tend to land in a project like this, so the pinning decision matters more than it would in a library with a stable 1.x API. The repository also carries a CITATION.cff file, which is the machine-readable citation metadata to go with the paper below.

Citing the solver, and what the open core leaves out

If you use PyVRP in research, the README asks you to cite the paper by Wouda, Lan and Kool (2024), PyVRP: a high-performance VRP solver package, in the INFORMS Journal on Computing, volume 36, number 4, pages 943 to 955, with the DOI 10.1287/ijoc.2023.0055, and a preprint on arXiv. A BibTeX entry is included. This matters more than usual citation etiquette, because a solver's reported quality and its default parameterisation are part of what makes results reproducible, and a pinned version plus a citation is what lets a reader reproduce a table. The commercial side is described in a single tip block: Applied Routing provides consulting, custom development and PyVRP Enterprise, an extended and production-ready version of PyVRP, with a private Slack channel for discussing use cases, features and the roadmap. So the open package is the research and evaluation tool, and the paid tier is the supported production version with the compliance constraints added.

Editorial conclusion

PyVRP suits a research group or a logistics engineer who needs a solver with real modelling depth, an open source core, and a citation in the INFORMS Journal on Computing rather than a black box API, and the open version already covers the constraints most routing projects actually need. It is the wrong tool if your problem needs hours-of-service break planning, vehicle-client compatibility rules or load and shift balancing, since those are Enterprise features rather than open ones, and it is the wrong tool if you need a hosted service, because there is no managed offering described here. Verify first which of your constraints fall on the open side of that line, since the README draws it explicitly, and check the version you are pinning against the 0.14.1 release, because the package manifest already reads 1.0.0a0 while the tags are still on 0.x and the last push was on 2026-10-17.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. PyVRP/PyVRP on GitHub
4. README
5. Releases