FAQ

ForgeKit is a local development environment for Windows. It installs and manages PHP, Apache, Nginx, MySQL, MariaDB and Node for you, so you can run your PHP projects on your own machine.

The main thing that makes it different is that it runs several independent web servers at the same time. One project can use PHP 5.6 while another uses PHP 8.5, both running together, with no global PHP version to switch between.

See What is ForgeKit? for a longer introduction.

Yes. ForgeKit is free for both personal and commercial work.

There is no paid tier, no trial, no feature behind a paywall and no account to create. You can use it for client projects without buying a licence.

If you want to support development you can contribute voluntarily, but it unlocks nothing, because there is nothing to unlock.

No. ForgeKit itself is closed source. The public GitHub repository is for issues, feature requests and discussion, not the application code.

That said, you are not locked in. Everything ForgeKit generates is ordinary Apache, Nginx, PHP and MySQL configuration. Your projects stay in normal folders and your virtual hosts are standard config files, so nothing you build depends on ForgeKit continuing to exist.

XAMPP gives you one Apache, one PHP and one MySQL shared by everything on the machine. Laragon is friendlier and lets you switch the active PHP version, but you still switch it globally.

ForgeKit lets you create several separate environments and run them at the same time, then attach each site to the one it needs. Nothing has to be switched.

There is a longer, sourced comparison in Best Local PHP Development Environments for Windows.

No. ForgeKit runs real Windows binaries directly.

There is no Docker, no WSL and no virtual machine involved, which is why it starts quickly and works the same on machines where WSL is not available.

No. ForgeKit is Windows only, and is built specifically around how Windows handles services, paths and permissions. It runs on Windows 10 and Windows 11.

• Windows 10 or Windows 11
• An internet connection the first time, so ForgeKit can download the runtimes you pick
• Administrator access, but only when the Windows hosts file needs updating

See Installation.

Because ForgeKit is not code-signed yet.

Windows and browsers judge an installer partly on its signing certificate and partly on how many people have already downloaded that exact file. A new unsigned build has neither, so you may see:

• A warning from your browser when the installer downloads
• A Windows protected your PC SmartScreen prompt when you run it. Choose More info, then Run anyway

Once you allow it, the install continues normally.

After installation, ForgeKit's own files should not be flagged. Windows Defender is happy with current builds. Some earlier unsigned builds were occasionally quarantined by Defender's heuristics, which look at behaviour rather than at any known malicious file, and that whole episode is written up honestly in ForgeKit v1.8: The Completionist.

Code signing is planned. Until then, if a build ever is flagged, you can review the detection under Protection History in Windows Security before allowing it.

No. ForgeKit installs into its own folder and leaves your other tools alone. You can keep them installed and go back to them whenever you like.

The one thing they cannot share is port 80, because only one program can listen on it at a time. Stop whichever one you are not currently using and the other will work.

Mostly, yes. Everything ForgeKit installs lives in one folder, it runs no Windows services, and uninstalling means deleting that folder.

Four small things live outside it, because they cannot work from inside a folder:

• A managed block in the Windows hosts file, so myproject.test resolves to your machine
• A local certificate authority, created only once you enable HTTPS
• A ForgeKit\HostsUpdate scheduled task, so hosts updates do not ask for permission every time
• One entry in your user PATH, so the fkit command works

None of them change how anything else on your machine behaves. In particular, ForgeKit adds no php, node or composer shim, so those commands keep resolving exactly as they did before.

Runs Independent From Your System lists all four and how to remove them if you want nothing left at all.

Only to update the Windows hosts file, which Windows protects so that only administrators can change it.

ForgeKit does not run as administrator. It creates a task called ForgeKit/HostsUpdate whose only job is to run forgekit-hosts.exe and update the hosts file when a site is added or changed.

Yes, once the runtimes you want are downloaded. ForgeKit needs the internet to fetch PHP, Apache, Nginx or database binaries, and after that your sites run entirely offline.

There are no accounts, no licence checks and no telemetry, so nothing phones home while you work.

Nothing. Your project files were never moved anywhere special, and they are not stored in any ForgeKit format.

The configuration ForgeKit generated is ordinary Apache and Nginx config, so you can copy it into another stack, or point XAMPP or a server at the same folders. Your databases are normal MySQL or MariaDB data directories and can be exported with a standard SQL dump.

Yes, and this is the main reason ForgeKit exists.

Install the PHP versions you need, then create a separate web server instance for each:

• Instance A uses PHP 8.3
• Instance B uses PHP 7.4

Assign each site to whichever instance suits it. Both keep running, so nothing has to be switched when you move between projects.

See How to Run Multiple PHP Versions on Windows for how this works underneath.

Wherever you like. When you add a site you choose the folder, and ForgeKit is happy to serve a project that already exists somewhere else on your drive.

There is a <ForgeKit>/sites/ folder if you prefer to keep everything in one place, but it is a convention, not a requirement.

1. Point ForgeKit at your project folder, wherever it currently is
2. Create or use the default web server instance
3. Click Add a site, choose the local domain, the folder and the instance

The site should be running straight away.

For the database:

1. Install a MySQL or MariaDB binary and create a database server instance
2. Connect to it on port 3306, or whichever port it uses
3. Create the database and import your existing SQL dump

See Migrating to ForgeKit.

Yes. Alongside the versions ForgeKit offers, you can add compatible PHP, Node, Apache, Nginx, MySQL and MariaDB builds of your own, either from a local file or a catalogue URL.

See Binaries and Runtimes.

Check the following:

• Is the web server instance running?
• Is the site assigned to that instance?
• Is port 80 already used by another program?
• Did Windows block the hosts file update?

If you used a real domain such as example.com, try a .test domain instead.

Something else is listening on it. The usual causes are:

• XAMPP, WAMP or another local stack
• IIS, the web server built into Windows
• Occasionally Skype

Stop the conflicting program and ForgeKit will be able to start.

See Port 80 or 443 already in use.

If you used a real public domain such as example.com, your browser may redirect to HTTPS, apply a cached HSTS rule, or simply resolve the real site on the internet.

Use a development domain instead:

• .test
• .local
• .localhost

Check which instance the site is assigned to, and which PHP version that instance uses.

Then confirm which PHP you are actually running. In a terminal opened by ForgeKit:

php -v

Or from your own terminal, using the project aware command:

fkit php -v

If fkit is not recognised, open a new terminal window so it picks up the updated PATH.

ForgeKit separates installed binaries from running instances. You install Apache 2.4.65 once, then create as many instances from it as you like, each with its own ports, PHP version, virtual hosts and logs.

See How ForgeKit Works or Instances.

Each web server instance has its own vhosts.conf. Sites on different instances appear in different files, even when both instances run the same Apache version.

See Site missing from vhosts.conf?.

PHP writes to its own php_error.log, kept separate from the web server's error.log, the same way a real server does.

You will find it inside the instance the site is assigned to:

/ForgeKit/instances/web/{instance_folder}/logs/php_error.log

It is shared by every site on that instance, so there is no per-site php_error.log. Open it from the second Logs button, under the PHP section of a web server's row.

See Where are logs stored?.

That log is the default for a PHP version when PHP runs outside any instance, such as in a terminal or through phpMyAdmin. Normal web requests are written to the site log or the instance's php_error.log instead, so an empty fallback log is expected.

See Where are logs stored?.