Why I still run Laragon, not Docker, for Symfony development

Background

Every "how do I set up local PHP development" thread ends up in the same place: someone recommends Docker Compose, because it's what most teams run in production-adjacent environments and it genuinely does solve a real problem - "works on my machine" stops being a joke when everyone's container is built from the same image.

I don't run it, and the reason isn't that I don't rate Docker. It's that the problem it solves - a team of people on different OSes needing byte-identical environments - isn't the problem I actually have most of the time. A lot of what I build is solo or small-team Symfony work on Windows, and for that, Laragon gets me from "new project folder" to "working .test URL with the right PHP version" faster than a docker-compose up and a wait for images to pull, with a lot less to go wrong afterwards.

Setup

The day-to-day workflow

What actually happens, project to project:

• Every folder under C:\laragon\www\ becomes <foldername>.test automatically, once Apache's picked up the change - no vhost file to hand-write, no /etc/hosts entry to remember. New Symfony project, git clone, refresh, it's live.
• PHP version switching is a right-click, not a rebuild. I keep 8.1, 8.3 and 8.4 installed side by side under C:\laragon\bin\php\, and Laragon's menu swaps the active one in seconds when an older client project needs it. No image to rebuild, no container to restart.
• MySQL comes with HeidiSQL wired in already - one click from the Laragon menu opens a real GUI against the local database, which covers most of what I'd otherwise reach for a CLI or a separate tool for.
• Composer and the Symfony CLI just run - C:\laragon\bin\php\<version>\php.exe isn't on PATH by default, so I call it explicitly rather than fighting Windows' PATH precedence when I've got three PHP versions installed at once. One line in a project's own notes saves re-discovering this every time.
• Xdebug is a checkbox, not a container layer with its own network quirks to reason about when the debugger won't connect.

Setting up a new Symfony project, step by step

The actual sequence for a brand new project, start to a working local URL:

1. Clone or create the project folder directly under C:\laragon\www\. The folder name becomes the domain, so name it what you want the .test URL to be.
2. Right-click Laragon's tray icon, pick "Reload" to pick up the new vhost - Apache's config regenerates from the folder list, no manual entry needed.
3. Switch to the PHP version the project needs from the same menu, if it isn't already the active one.
4. Run Composer install via the full path, e.g. C:\laragon\bin\php\php-8.4.26-Win32-vs17-x64\php.exe C:\laragon\bin\composer\composer.phar install
   • or add that PHP version's folder to a project-local script so it's not retyped every time.
5. Create the database from HeidiSQL (one click from the Laragon menu) and point .env.local at it - 127.0.0.1, the default Laragon MySQL port, root with no password unless you've changed it.
6. Run migrations, then open <foldername>.test in a browser. If it doesn't resolve, "Reload" again - it's almost always a vhost cache that hasn't picked up the new folder yet, not a real DNS problem.

Where Docker actually wins, and I'd reach for it

This isn't a blanket case against Docker - it earns its overhead in specific situations that are worth naming honestly:

• A service version pinned exactly to production - a specific Redis or Elasticsearch build a Dockerfile can lock precisely, where Laragon just gives you whatever version you installed and forgot the exact number of.
• A genuinely mixed-OS team, where someone's on macOS and someone's on Windows and "it works for me" has already cost a day chasing a PHP extension mismatch that a shared image would have prevented outright.
• A project with several interdependent services - a queue worker, a cache, a search index, all needing to come up together in a known state - where docker-compose up genuinely beats manually starting and configuring each one by hand.

Docker earns its overhead when parity is the problem. On a Windows machine building mostly solo, it usually isn't - the overhead of maintaining Dockerfiles and rebuilding images is a real ongoing cost, not a one-off setup tax, and it's not worth paying for a parity problem that doesn't actually exist on a given project.

What breaks when this meets production

The gap between "works on Laragon" and "works on the live server" is smaller than it looks, but it's real, and it's worth knowing exactly where it sits before a first deploy rather than discovering it live:

• Filesystem case sensitivity. Windows doesn't care about Controller.php vs controller.php; Linux does.
• Line endings. Windows tooling defaults to CRLF; Linux and CI expect LF.
• PHP and MySQL minor version drift. Laragon's installed versions aren't guaranteed to match the server's exactly.
• File permissions. Windows has no real equivalent of Linux's execute/write permission bits, so a script that needs to be executable or a directory that needs to be writable on the server is invisible as a problem until it's actually deployed.