Runs Independent From Your System

Overview

ForgeKit is designed to run completely independently from your system.

Everything lives inside a single folder, fully isolated from your machine. Your existing setup remains untouched. Nothing breaks, nothing gets overwritten, and nothing is modified globally.

Safe alongside your existing setup

ForgeKit can run side-by-side with tools like:

  • XAMPP
  • WAMP
  • Laragon
  • Custom local environments

There is no interference between ForgeKit and your current setup. You can keep everything you already use and try ForgeKit without risk.

Port usage

ForgeKit uses standard web ports to behave like a real server environment. The ForgeKit router listens on port 80 (HTTP)

Because of this:

  • Only one application can use port 80 at a time

If another tool (like XAMPP or WAMP) is running on port 80, Apache or Nginx or whatever is listening to port 80 must be stopped.

Running alongside other tools

ForgeKit can coexist with other environments, but not share the same ports simultaneously.

You can:

Stop XAMPP/WAMP Apache server → run ForgeKit

Stop ForgeKit → run your other tool

This ensures each environment runs cleanly without conflicts.

No system changes

ForgeKit does not:

  • Install or run Windows services
  • Install anything system-wide
  • Register file associations or COM components
  • Leave anything running once you close it

Almost everything ForgeKit uses is scoped to its own directory. There are four exceptions, because they cannot work from inside a folder:

What Why it exists
A managed block in the Windows hosts file So myproject.test resolves to your own machine. See Vhosts and Routing.
A local certificate authority in the Windows trust store So local HTTPS is trusted by your browser. Only created once you enable HTTPS. See SSL and HTTPS.
A scheduled task, \ForgeKit\HostsUpdate So updating the hosts file does not ask for elevation every single time.
One entry in your user PATH So the fkit command is available in any terminal. See Terminal.

Each one only ever applies to ForgeKit's own work. The hosts entries only affect domains you asked ForgeKit to create, the certificate authority only validates certificates ForgeKit issued, and the scheduled task only runs when ForgeKit calls it.

About the PATH entry

The PATH entry is the one worth being precise about, because this is where local development tools usually cause trouble.

ForgeKit appends <AppRoot>\cli to your user PATH (stored in HKCU\Environment, so it needs no administrator rights and does not affect other accounts on the machine). That directory contains a single runnable command: fkit.

It contains no php, node or composer shim. Running php -v in your own terminal after installing ForgeKit does exactly what it did before, and so does every build script and IDE integration that depends on it. ForgeKit resolves a project's own versions only when you explicitly ask it to, by running fkit php -v instead.

Fully self-contained

All ForgeKit components are stored within its installation folder:

  • /bin → installed runtimes (PHP, Apache/Nginx, MySQL/MariaDB)
  • /agent → golang agent .exes
  • /cli → golang cli tool
  • /certs → ssl certificates that ForgeKit auto generates
  • /instances → running servers and their configs
  • /sites → your project mappings
  • ForgeKit.yaml → configuration
  • ForgeKit.exe → application

Because of this:

  • You always know where everything is
  • Nothing is scattered across your system
  • Cleanup is simple and predictable

Easy to remove

Removing ForgeKit is straightforward:

  1. Stop any running instances
  2. Delete the ForgeKit folder

That removes ForgeKit itself, along with every runtime, instance, config, certificate and log it created. There are no cleanup scripts to run and nothing is scattered across your drive.

Removing it completely

The four items above live outside the ForgeKit folder, so deleting the folder does not remove them. None of them do anything once ForgeKit is gone. The PATH entry points at a directory that no longer exists, the scheduled task has nothing left to run, and the certificate authority has no certificates left to validate. Leaving them in place is harmless. If you would rather have nothing left at all:

  • Hosts entries. Open C:\Windows\System32\drivers\etc\hosts as an administrator and delete the ForgeKit block. Its lines end in # ForgeKit.
  • Certificate authority. Open certmgr.msc, go to Trusted Root Certification Authorities → Certificates, and delete ForgeKit Local Root CA.
  • Scheduled task. Open Task Scheduler and delete the ForgeKit folder, which contains a single HostsUpdate task.
  • PATH entry. Open Edit environment variables for your account and remove the ...\ForgeKit\cli entry from Path.

Why this matters

Local development tools often:

  • Share global resources, so one project's PHP version becomes every project's PHP version
  • Put shims on your PATH, so ordinary commands quietly start behaving differently
  • Scatter runtimes, data and configuration across the drive
  • Interfere with other environments already installed

ForgeKit avoids this by keeping its own copy of everything in one place, and by resolving tools per project rather than globally.

Summary

ForgeKit is built to be:

  • Safe to try
  • Easy to understand
  • Simple to remove

It runs independently, respects your system, and gives you full control.