Every PHP your projects need, in seconds

pv install 8.4          # a complete PHP, extensions included
cd ~/code/legacy && pv pin 7.4
php -v                  # PHP 7.4.33
cd ~/code/new && php -v # PHP 8.4.21

The problem is not installing PHP once

It is installing PHP five times — one per project that pinned a different version — and keeping each one straight.

Today that means a package manager that holds one PHP at a time and breaks the others when it upgrades. Or a ./configure incantation, forty minutes of compiling, and a php -m that is missing the one extension your app needs. Or Docker, and now every php you type is a container boundary away from your editor, your debugger and your test runner.

pv downloads a finished PHP. No compiler, no toolchain, no system packages. It unpacks and it runs.

Everything already compiled in

60 extensions in every build — intl, imagick, gd, redis, mongodb, sodium, all three PDO drivers — plus Xdebug, which has to ship as a shared library and usually does not ship at all.

Right outside your terminal too

Resolution runs through real files on PATH, not a shell hook. Editors, language servers, CI runners, cron jobs and git hooks inherit PATH and nothing else — a hook never fires for them, and they quietly use the wrong PHP. pv’s shims do not have that problem.

The old versions, too

7.4 and 8.0 are where a version manager earns its keep, and they are the hardest to build — modern libxml2 and ICU broke their source outright. pv patches around that so the lines you are actually stuck on are first-class.

Verified, or not installed

Every artifact is checked against a published sha256 before extraction, and verification fails closed: a missing or malformed hash is an error, never a reason to skip the check.

What a version switch costs

1. Install once per version. pv install 8.4 fetches one tarball and unpacks it. Nothing is compiled, so this takes about as long as the download.

2. Pin per project. pv pin 7.4 writes a one-line .php-version you commit. Everyone on the project gets the same runtime.

3. Switch by changing directory. No shell reload, no daemon, no use command. cd and php is a different PHP.

What pv is not

It does not replace Composer. pv does not resolve dependencies and has no opinion about your vendor/ directory. It is the runtime half: getting a correct PHP onto the machine and pointing the right commands at it. Composer stays exactly as it is — and pv run composer install runs it under whichever PHP the current directory resolves to.

It does not manage your sites. No web server, no process supervisor, no .test domains. One job.

Why the extensions are fixed

These builds are statically linked, which is what makes them relocatable and dependency-free — and it means PHP cannot dlopen an extension that was not compiled in, so pecl install does not work against them. The extension list is the supported surface, and it is generated from the build scripts rather than written by hand, so it cannot claim something a build does not ship.

Where it runs

macOS and Linux, on both Apple Silicon and x86_64, each built on a native runner. The client itself is a single static Rust binary with no runtime dependencies. Windows is not supported.

See platforms for the full matrix and the one caveat that matters on Linux — a glibc floor, taken deliberately so Xdebug can load.