Laragon: a portable PHP, Node.js and Python stack for Windows

What Laragon replaces on a Windows machine

Laragon targets developers who build web applications on Windows and do not want to assemble Apache, Nginx, MySQL, PostgreSQL, MongoDB, PHP, Node.js and Python by hand. The README frames it as a "portable, isolated, fast & powerful universal development environment" and says it is aimed at building and managing modern web applications. The isolation claim matters more than it sounds: the README states that Laragon does not use Windows services and instead runs its own "service orchestration" that manages services asynchronously and non-blocking. That is the architectural difference from a stack that registers each daemon with the operating system. If you delete the folder, you are not left with orphaned services, and moving the folder to another disk or another machine is presented as safe.

The audience is narrow in one respect and broad in another. Narrow because the shipped entry point is laragon.exe at the top level of the repository, and the README explicitly says you may need the installer so it can detect and install the Visual Studio C++ runtime components that PHP and Apache depend on. Broad because the same folder is meant to host several language runtimes and several database engines at once, with the README claiming you can add another version of PHP, Python, Ruby, Java, Go, Apache, Nginx, MySQL, PostgreSQL or MongoDB "effortlessly" by extracting it into Laragon's bin folder. The repository layout backs that up: bin/, etc/, usr/ and www/ sit alongside the executable, which is the shape of a self-contained tree rather than an installed application.

Pretty URLs, auto-config and the bin folder

The mechanism the README leans on is auto-configuration. Where other stacks ask you to edit httpd.conf or a vhost file, Laragon is described as configuring the complicated parts itself, so adding a second PHP version or switching between Apache and Nginx does not require touching configuration files. The visible payoff is pretty URLs: a project in the www folder is served as app.test instead of localhost/app. That is the single most concrete behaviour described, and it is the one that changes day-to-day work, because it removes the path prefix from every local URL and makes cookie and asset paths behave closer to production.

Service management is the second mechanism. Because Laragon does not register Windows services, its orchestration layer starts and stops the bundled daemons itself, which is why the README can claim instant startup and a small memory footprint. The stated numbers are under 6MB for the core binary and roughly 4MB to 10MB of RAM while running. Those are the project's own figures, not measurements I can confirm.

Extension into the stack happens by filesystem, not by a package manager. The README says you add services by extracting them into Laragon's bin folder. That is simple and it is also the main constraint: there is no resolution step, no version solver and no lockfile, so you are responsible for knowing which PHP build matches which Apache build. The one-click actions the README lists (a WordPress install, sharing a local project with a customer, toggling a PHP extension) are conveniences layered on top of that same folder, not a separate provisioning system.

Installing Laragon on Windows and serving a first project

The README says installation is a download followed by clicking Next through the wizard, and that the installer is worth using because it detects and installs missing Visual Studio C++ runtime components needed by PHP and Apache. The repository does not document a command-line installer, a package manager entry or a silent-install flag, so the wizard is the documented path. There is no install command to show here; the download comes from the project's homepage, https://laragon.org.

Once the stack is running, the documented workflow is to place a project inside the www folder and reach it by name plus .test. The README's pretty URL scheme means a project in www is opened at its .test name rather than under localhost. If the page resolves, the auto-configuration has registered the host and pointed the web server at the folder; if it does not, the failure is in the orchestration layer rather than in your own files.

To add a runtime rather than a project, the README's instruction is to extract it into the bin folder. The expectation is that Laragon picks the new version up and offers it in its menus without you editing a configuration file. The README does not describe how version selection is persisted, so if two PHP builds are present, which one a given project receives is not documented in the repository.

The licence requirement and what the repository does not say

The README carries a note that starting with Laragon 7.x a licence is required to use Laragon, and points to https://laragon.lemonsqueezy.com/ for details. That is the whole of what the repository states on the subject. It does not name the licence, does not say whether older 6.x builds remain usable, does not describe what happens when a licence lapses, and does not say whether the portable folder can be copied to a second machine under the same licence. Anyone planning to standardise a team on Laragon has to resolve those questions at the purchase link, not from the repository.

The repository metadata itself lists the licence as unknown, and the top-level entries are documentation and application folders (.github/, bin/, etc/, usr/, www/) plus laragon.exe. There is no LICENSE file in the listing. For an engineering decision that matters: you cannot read the terms from the source tree, and this article is not legal advice. Treat the licence as a procurement step, not a footnote.

The practical consequence is that Laragon is no longer the zero-cost default it was in the 6.x era. If your reason for choosing it was that it was free, that reason has expired, and the comparison against a free alternative changes accordingly.

Where Laragon is the wrong tool

The clearest limitation is platform. The repository ships laragon.exe and the README discusses Windows runtime components, Windows services and a Windows installer. There is no documented macOS or Linux build in the repository, so the searches for Laragon on Mac or Linux have no answer here. If your team is mixed-platform, Laragon solves the Windows half only, and you will need a second answer for everyone else.

The second limitation is the extension model. Extracting services into bin/ is easy to describe and hard to keep consistent. Nothing in the README describes dependency resolution between the web server and the language runtime, and nothing describes rollback if a newly extracted version misbehaves. A stack you assemble by hand is a stack you debug by hand.

The third is version drift. The recent releases listed for the repository are 8.7.0 on 2026-08-14, 8.6.1 on 2026-03-02 and 8.6.0 on 2026-02-14. That is a real cadence, and the last push to the repository was on 2026-08-14. But the README is written for the current line, and it does not document upgrade paths from 6.x or what a licence covers across major versions. If you are on an older build, the repository does not tell you what moving forward costs.

Finally, the absence of Windows services is a feature with an edge. Because Laragon manages its own daemons, anything else on the machine that expects to find MySQL or Apache registered as a system service will not find it. That is fine for a laptop and awkward for a build agent or a machine where other tooling assumes service discovery.

Laragon against XAMPP and against containers

The comparison people actually search for is Laragon against XAMPP, and the difference the README draws is auto-configuration. XAMPP ships a control panel that starts and stops components but leaves configuration to you; Laragon's stated design is to configure the complicated parts itself so you can add PHP, Apache, Nginx, MySQL, PostgreSQL or MongoDB versions without editing files. The other difference is the service model: Laragon states it does not use Windows services, while a conventional Windows stack registers its daemons with the OS. Whether that matters depends on whether you want the stack to survive a reboot on its own or to be something you start deliberately.

The alternative that is genuinely different in approach is a container-based development environment such as Docker Compose. Laragon gives you one shared set of daemons on the host, reachable at project.test, configured once. Compose gives you a per-project definition with pinned images, so two projects can run different MySQL majors at the same time without touching a bin folder. The trade is weight and ceremony: Compose needs a container runtime, image pulls and a YAML file per project, while Laragon's README promises instant startup and a footprint measured in single-digit megabytes. If you want one stack for many projects on one Windows machine, Laragon's model is lighter. If you want reproducibility across machines and CI, the container model is doing work Laragon does not attempt, because Laragon's extension mechanism is a folder you fill yourself.

Editorial conclusion

Laragon suits Windows developers who want a PHP, Node.js and Python stack in a folder they can move or sync, and who accept the licence requirement that starts with 7.x. It is the wrong tool if you work primarily on macOS or Linux, since the repository ships a laragon.exe and the README describes a Windows runtime component installer. Before adopting it, verify the licence terms and price at the Lemon Squeezy link the README gives, and check whether the licence identifier is stated anywhere you need it, because the repository metadata does not carry one.

Frequently asked questions

Official sources

1. Issues
2. leokhoa/laragon on GitHub
3. Project website
4. README
5. Releases