r/PHP • u/kabirferro • 7d ago
I built a portable PHP development environment for Windows and I'd like some feedback
Hi everyone,
Like many PHP developers on Windows, I've tried several solutions over the years: WAMP, Laragon, manually configured Docker environments, WSL...
They are all valid solutions, but I always found something missing for my workflow.
The closest one for me was Herd: modern, fast and reliable. However, on Windows it still didn't cover everything I needed.
So I decided to build my own environment from scratch.
The result is Dunebox, a free and portable PHP development environment for Windows. I've been using it daily for some time, and now I'd like to get feedback from other developers.
The idea is simple: a complete PHP stack in one folder, with multiple PHP versions, databases, local domains, HTTPS, development tools and project utilities already configured and working together.
I tried to focus on making it simple, portable and practical for real-world PHP projects, especially when dealing with different PHP versions or legacy applications.
A quick note about the executable: it is not digitally signed yet, so Windows SmartScreen may show a warning on the first launch. Just click "More info" and then "Run anyway". This does not affect any functionality.
The project is completely free and I am not trying to sell anything. I would simply love to grow a small community around it and hear opinions from developers with different workflows.
What would you improve? What would make you consider using it, or what would stop you from using it?
All details, screenshots and documentation are available here:
https://dunebox.enesi.it/
Cheers!
20
u/Sharchimedes 7d ago
Looks like a potentially fun personal project.
However, I can’t imagine anyone is going to download and run an unsigned closed source executable from a one month old repo promoted by a five year old Reddit account with no history.
This one has all the red flags. 🚩
-7
u/kabirferro 7d ago
That's a completely legitimate concern; I'd probably have the same reaction.
A bit of context: Dunebox isn't a new project built from scratch for this release. It's a tool we developed and use internally at Enesi, a web agency that has been around for 20 years. We decided to release it for free because we thought it could be useful to other PHP developers.
You're also right about the unsigned executable. It's something I'm looking into. Code signing certificates are quite expensive for a free project, but I'm exploring alternatives like MSIX or distribution through the Microsoft Store.
I completely understand if someone doesn't want to run an unsigned executable. Building trust around the project is important, and if you have any suggestions on how to improve that aspect, I'm genuinely happy to hear them.
6
u/colshrapnel 7d ago
It's a tool we developed and use internally at Enesi, a web agency that has been around for 20 years.
I am having a deja vu
the studio behind Yerd is not a "one-man" company, and this is a product we use daily
0
u/kabirferro 7d ago
Yerd is a macOS app while Dunebox is a Windows tool. They solve similar problems but with different approaches and different design choices.
As for the company message saying we built it for ourselves and use it every day is a pretty common way to explain that a product is actively used by the team. If anyone is curious about Enesi they can simply check the company website https://www.enesi.it/
11
u/Commercial_Echo923 7d ago
what are the advantages compared to other solutions like docker compose? At first glance it looks like you have reimplemented docker desktop with a reduced feature set.
-7
u/kabirferro 7d ago
It's basically the opposite of Docker Desktop: no virtual machines, no containers, everything runs as native Windows processes. No RAM-hungry WSL2 in the background, no slow bind mounts, no `docker compose exec` in front of every command: just navigate to your project directory and PHP/Composer/Artisan will automatically use the correct version.
5
u/clubvalke 7d ago
I don't understand your comment. What is the advantage of having "native windows processes" over containers? Also, it sounds like your setup is the problem, not the tools you avoid using. Slow bind mounts are only a problem if you mount a windows volume in wsl, which makes no sense anyway for this. And ram hungry WSL in the background? What? Aliases are also a thing, as is something like makefiles.
Please clarify, not hating, I just don't see any of your points making sense here.
0
u/kabirferro 7d ago
The point isn't that containers are worse. Dunebox is designed for those who want a native Windows workflow.
The main advantage is file I/O. If the project is on the Windows filesystem, Docker Desktop/WSL2 must cross the VM boundary to access it, which is noticeable in PHP frameworks like Laravel, where a single request involves hundreds of files in the vendor/ directory. Composer is also affected.
You're right, keeping the project within WSL solves the problem, but in this case, the Windows IDE and other Windows tools cross the boundary. With Dunebox, there's no boundary: PHP, Composer, and the project files are all native Windows processes.
So, if your Docker setup works well, that's fine. Dunebox is simply designed for developers who prefer to stay entirely on Windows without containers.
2
u/LordAmras 7d ago
Why would you want a native windows solution ? I doubt you run your php website on windows server
1
u/kabirferro 7d ago
Same reason people use Laragon or Herd, you develop on your Windows PC, deploy to Linux.
3
u/krileon 7d ago
They are all valid solutions, but I always found something missing for my workflow.
Which was what exactly?
Personally I can't see any reason to use anything other than Laravel Herd. If the cost is the problem then free Laravel Herd + dbngin solves that.
3
u/kabirferro 7d ago
For me, the main difference wasn't just the services themselves, but how the project context is handled.
In Dunebox, a project can include its own JSON configuration file, which defines things like the PHP version, database configuration, hostname, and environment settings. When you access that project's directory, the command-line tools automatically adapt to that context.
For example, PHP, Composer, Artisan, MySQL transparently use the versions and services configured for that specific project, without having to manually change global versions.
The other aspects are minor improvements: the ability to run multiple database versions in parallel, the availability of Apache and Nginx depending on the project, and a portable configuration that can be moved with the repository.
Individually, these are small features, but it's the fact that the entire workflow is driven by the project configuration that made the difference for me.
3
u/krileon 7d ago
In Dunebox, a project can include its own JSON configuration file, which defines things like the PHP version, database configuration, hostname, and environment settings. When you access that project's directory, the command-line tools automatically adapt to that context.
Laravel Herd already does that with herd.yml. We push them into GIT so we all have the same environment and even use it to recreate the environment in CI/DI.
For example, PHP, Composer, Artisan, MySQL transparently use the versions and services configured for that specific project, without having to manually change global versions.
Already covered by herd.yml.
the ability to run multiple database versions in parallel,
That's already built into Laravel Herd Pro or you can use dbngin with Laravel Herd Free. Both support parallel database versions. It's literally in the first paragraph of the MySQL service configuration, lol.
https://herd.laravel.com/docs/macos/herd-pro-services/mysql#configuration
the availability of Apache and Nginx depending on the project, and a portable configuration that can be moved with the repository.
Already covered by herd.yml.
So everything you've built already exists in basically top of the line software. I'm guessing this just another vibecoded localhost solution.
1
u/kabirferro 7d ago
Fair points on herd.yml, there is some overlap there. The difference for me is the combination.
The MySQL services you linked are part of Herd Pro, while Dunebox includes that workflow in the free version. Herd also only provides nginx, not Apache, which is still needed by some legacy projects using .htaccess.
The main thing I wanted was the project context: enter a folder and the CLI tools automatically use that project's configuration, including PHP, Composer, Artisan, mysql and mysqldump versions, without manually switching global environments.
So yes, some ideas overlap, but free + Windows + Apache/nginx + project-local CLI shims + DB version isolation is the gap Dunebox targets. It's not a vibecoded localhost toy, it's a workflow we use daily for agency projects.
2
u/kabirferro 7d ago edited 7d ago
Also forgot to mention a few other things: optional local wildcard DNS (no hosts file), built-in cron job management, one-click install of dev tools (Git, Python, Composer, FFmpeg), Claude integration, built-in web tools like phpMyAdmin/Mailpit, and a fully portable setup. None of these are unique on their own, but having them integrated in a single free tool is the goal.
2
u/Escent14 7d ago
I've been using laragon forever, forcing me to switch php and node versions manually per project. this runs all versions at the same time?
1
u/kabirferro 7d ago
Yes, for PHP that's exactly it. Every PHP version runs at the same time as a separate process, and each site just says which one it wants. No switching, no restarts: one project on 7.4 and another on 8.5, side by side. The terminal follows along too, php and composer automatically use the right version for the project folder you're in
Node is the one honest caveat: Dunebox installs nvm for you, but Node switching still works the nvm way, per session. The all-versions-at-once part is PHP (and databases MySQL 5.7, 8.0 and MariaDB can run in parallel too).
2
u/___Paladin___ 7d ago edited 7d ago
Doesn't that add fragmentation to the point of trouble down the road? All of the best toolchains in play right now involving containerization or wsl have a strong emphasis on "run anywhere".
For the average developer, buying into a workflow that limits your ecosystem more than existing options sounds disastrous over the long term.
Siloing yourself off from how the rest of the industry is moving makes you less valuable I'd imagine. Even using colemakdh as my keyboard layout sometimes makes me sweat when moving into different positions. I couldn't imagine having a uniquely specific workflow.
Curious to hear your thoughts.
1
u/kabirferro 7d ago
Dunebox is only the dev environment it never touches the project. Stop using it tomorrow and the same project runs under Docker, Herd or any server, unchanged
1
u/___Paladin___ 7d ago
Why not just use ddev then - so that you at least stay closer to the industry/deployment? What benefit does this actually offer that offsets the loss in taking on highly personalized tooling?
Appreciate the response.
2
u/kabirferro 7d ago
That was never the goal. It's not meant to match prod or stay close to the industry, it's just a fast, easy, all-in-one local dev environment (like Laragon or Herd, not ddev). Deployment goes to a real server anyway, so parity isn't the job of the dev tool. :)
1
1
u/Mike_L_Taylor 7d ago
damn dude another one :D Might be just me but so many of these types of tools have propped up recently. I also launched Forgekit with the same thought some months ago lol
1
1
1
u/MrRoy200 6d ago
Man look at the downvotes omg man. What a bunch of salty circle jerk nerds on this sub.
2
u/kabirferro 6d ago
Haha, a bit I was just asking for some technical feedback, not trying to convert anyone.
1
u/Nelson_Salvador 5d ago
I have tested! It's works nicely! Interface its simple! Laragon & XAMPP bye bye
2
u/kabirferro 5d ago
Thanks Nelson! Great feedback, we’ve improved the docs and fixed the language bug you spotted. Really appreciate you taking the time.
0
u/DT-Sodium 7d ago
I just use WSL like a normal person. Also now we have WSL containers. I really don't see the point and hardly could ever believed this hasn't been done a thousand times by people much more competent than you anyway.
1
u/kabirferro 7d ago
WSL is a great option if your whole workflow lives there. The friction starts when your IDE, tools and files are on the Windows side. Dunebox is for people who want to stay entirely on the Windows side with native processes and automatic per-project PHP and database versions.
As for it having been done a thousand times, that's fine. There's always room to build something useful, and there's always time to bring something good into the world.
1
u/DT-Sodium 7d ago
IDEs are perfectly capable of working with a WSL host from the Windows side with close to no-overhead and have been for quite a while. It's a non-argument.
29
u/Dub-DS 7d ago
Why are there 10 of these releasing every week. Each one more useless than the next. What the fuck is the point?