How to Run Multiple PHP Versions at the Same Time on Windows

The short answer

• Yes, you can run several PHP versions at once on Windows. Each version is its own set of programs, and Windows runs them side by side like any other programs.
• There are two ways to do it: a separate web server for each PHP version, or one web server that hands each site to a different PHP process.
• Most local tools switch rather than run side by side. XAMPP has one PHP, and Laragon switches its one active version from the menu. That's fine until two projects need different versions on the same day.
• The versions that matter right now: PHP 8.5 is current, 8.6 is due on 19 November 2026, and 8.2 stops getting security fixes on 31 December 2026. 7.4 and 8.0 are long past end of life but still run plenty of client sites.

You can build either setup by hand. The rest of this guide shows how. Or let a tool that runs versions side by side do it for you: that's what I built ForgeKit for.

Adding a second PHP version to XAMPP

XAMPP's Apache can do this without a second XAMPP. Keep its built-in PHP for most sites, and send one site to another PHP version running as a separate FastCGI process. It's the "one server, several PHP versions" approach described further down.

1. Download the other PHP version from php.net (for example PHP 8.5, x64 Non Thread Safe) and unzip it to its own folder, such as C:\php\8.5. Create its php.ini from php.ini-development.
2. Start it as a FastCGI process: C:\php\8.5\php-cgi.exe -b 127.0.0.1:9085
3. In xampp\apache\conf\httpd.conf, make sure mod_proxy and mod_proxy_fcgi are loaded (uncomment their LoadModule lines).
4. In that site's virtual host, hand PHP files to the new process: <FilesMatch "\.php$"> SetHandler "proxy:fcgi://127.0.0.1:9085" </FilesMatch>
5. Restart Apache. That site now runs on PHP 8.5, and every other site stays on XAMPP's own PHP (8.2 if you're on XAMPP 8.2.12).

The catches:

• php-cgi.exe has to be running before you open the site, and it doesn't start with XAMPP. You start it yourself or with a script, every time.
• Each extra version needs its own folder, php.ini, port and start command.
• Command-line tools such as Composer and artisan use whichever php.exe is first in your PATH, not the site's version. Call the right one by its full path.

It works, and for one extra version it's a reasonable afternoon. Past two or three versions, keeping track of the processes and ports becomes its own job, which is the part ForgeKit automates.

The quickest proof: PHP's built-in server

PHP includes a small development server of its own.

Open two terminals and run two different PHP executables:

C:\php\5.6\php.exe -S 127.0.0.1:8056 -t C:\sites\legacy
C:\php\8.4\php.exe -S 127.0.0.1:8084 -t C:\sites\modern

You now have:

http://127.0.0.1:8056 → PHP 5.6
http://127.0.0.1:8084 → PHP 8.4

Both versions are running simultaneously because they are separate processes listening on separate ports.

PHP's built-in server is intended for development and testing rather than as a full web server. On Windows it also runs as a single-threaded process, so it is useful as a demonstration or lightweight project server, but Apache or Nginx gives you a more complete environment.

Approach two: one Nginx server with several PHP versions

You do not have to run several Apache or Nginx servers.

Another clean architecture is:

One Nginx server
Multiple PHP FastCGI processes

Nginx handles HTTP for every site on port 80.

Each PHP version runs independently on a different internal FastCGI port:

PHP 5.6 → 127.0.0.1:9056
PHP 7.4 → 127.0.0.1:9074
PHP 8.4 → 127.0.0.1:9084

The browser never connects to these PHP ports directly. They are only used for communication between Nginx and PHP.

On Windows, the executable is normally:

php-cgi.exe

not PHP-FPM. PHP's documentation notes that PHP-FPM is unavailable on Windows, while Nginx's FastCGI module forwards requests to a FastCGI backend with fastcgi_pass.

A basic local setup can start the PHP processes like this:

C:\php\5.6\php-cgi.exe -b 127.0.0.1:9056 -c C:\php\5.6\php.ini
C:\php\7.4\php-cgi.exe -b 127.0.0.1:9074 -c C:\php\7.4\php.ini
C:\php\8.4\php-cgi.exe -b 127.0.0.1:9084 -c C:\php\8.4\php.ini

Then each Nginx server block chooses its required PHP backend.

PHP 5.6 site

server {
    listen 80;
    server_name legacy.test;
    root C:/sites/legacy/public;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass 127.0.0.1:9056;
    }
}

PHP 8.4 site

server {
    listen 80;
    server_name modern.test;
    root C:/sites/modern/public;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass 127.0.0.1:9084;
    }
}

Both sites use the same Nginx process and the same browser port.

The important difference is this one line:

fastcgi_pass 127.0.0.1:9056;

versus:

fastcgi_pass 127.0.0.1:9084;

That line determines which PHP process executes the request. Nginx's official documentation describes fastcgi_pass as the connection to the FastCGI server and shows SCRIPT_FILENAME being passed so PHP knows which file to execute.

Apache can do this too

This is not limited to Nginx.

Apache can also send PHP requests from different virtual hosts to different FastCGI backends through mod_proxy_fcgi.

Conceptually:

<VirtualHost *:80>
    ServerName legacy.test
    DocumentRoot "C:/sites/legacy/public"

    <FilesMatch "\.php$">
        SetHandler "proxy:fcgi://127.0.0.1:9056"
    </FilesMatch>
</VirtualHost>

<VirtualHost *:80>
    ServerName modern.test
    DocumentRoot "C:/sites/modern/public"

    <FilesMatch "\.php$">
        SetHandler "proxy:fcgi://127.0.0.1:9084"
    </FilesMatch>
</VirtualHost>

Apache's mod_proxy_fcgi supports selecting a FastCGI host and port from server or virtual-host configuration.

Nginx simply makes the separation particularly easy to understand.

How ForgeKit organises this

ForgeKit turns the underlying pieces into three concepts:

Runtimes

The actual installed software:

• PHP 5.6
• PHP 7.4
• PHP 8.4
• Apache 2.4
• Nginx
• MySQL
• MariaDB

Instances

Independent configured servers built from those runtimes:

• Legacy Apache
• Client PHP 7.4
• Modern Nginx
• Old MySQL 5.6
• Current MariaDB

Sites

Projects connected to a particular web-server instance:

legacy-client.test → Legacy Apache → PHP 5.6
shop.test          → Client Apache → PHP 7.4
new-app.test       → Modern Nginx  → PHP 8.4

ForgeKit assigns the internal ports, writes the virtual-host files, updates the Windows hosts file, creates the logs and configuration folders, and starts and stops the processes.

The underlying idea remains simple:

Different executable files, running as different processes, listening on different ports.

You can absolutely assemble that architecture yourself.

ForgeKit exists because doing it repeatedly, remembering every port, generating every configuration file and managing every process eventually becomes its own project.

• Your projects stay where they are. You point a site at its existing folder.
• XAMPP or Laragon can stay installed. Stop their web server while ForgeKit runs, because only one program can own ports 80 and 443.
• Free, including for commercial work. No licence, no account.

Frequently asked questions