“Magento DevBox” is the name for a new Magento 2 development environment under development. It is being built by Magento as a standard way to develop Magento 2 sites for developers on a local development machine (a laptop or desktop). It is built upon Docker, but should not be confused with other Docker projects intended for production usage. Docker was a convenient technology to simplify the installation of a range of services that are frequently used with Magento 2 development.
There are a number of other great community solutions out there, each with different pros and cons. If you are using one of these environments there may not be a strong reason to consider Magento DevBox instead. Magento DevBox is not “magic” – it just follows our own installation guidelines. Magento DevBox will however become the default answer from Magento for “how do I get going with Magento 2 development?”
Why Magento DevBox?
Why are we putting together Magento DevBox? As the sophistication of Magento has increased (compared to Magento 1), the number of technologies needed has also increased. We have not found an existing MAMP or WAMP like installation with the right set of tools to make local installation of such tools easy.
Another benefit of Docker containerization is it is easier to have multiple development environments installed with different versions of services (e.g. different versions of PHP and MySQL when Magento 2 changes the supported versions sometime in the future). You just start and stop the environment for the project you are working on (to reduce memory consumption). This is trickier to configure when services are installed natively.
We have also heard the having a standardized environment from Magento can improve efficiency within the community. Developers trained on a standard environment can more quickly move between projects when the same set of tools and practices are followed.
What is Magento DevBox?
Magento DevBox is a pre-made development environment for Magento 2 built using Docker. It supports a range of Magento 2 releases (CE, EE, and ECE – Enterprise Cloud Edition – although ECE is not fully available yet), including the option to load sample data (useful for testing). As well as the core web server and MySQL instance, configuration options include developing with local Redis (data cache), Varnish (page cache), Elastic search (search technology), and RabbitMQ (message queue) instances.
How does it Work?
Magento DevBox is currently built using Docker 1.12 based on their promise of lightweight containers and native file sharing.
With Magento DevBox, project source files are left on the native host file system (Mac or Windows), allowing native IDEs to access the files directly. This provides the most responsive development environment of all the variations we have tested. This also allows the DevBox environment to be destroyed and recreated at any time, without risk of loss of code.
To create a new Magento DevBox environment, an online web form is provided which asks a number of questions about what tools you want to use (e.g. do you want Redis installed). The final result is a ZIP file with all configuration settings preconfigured. You download and extract this ZIP on your local file system. This includes getting the Magento 2 code base (for new projects) and automatic injection of download keys streamlining the download experience.
There have been some bumps however. The new file sharing approach introduced in Docker 1.12 has performance issues on Mac. This has been worked around within the Docker containers for now by use of Unison to synchronize files between the mounted directory and the web server directory. This is generally transparent to developers and will be removed if Docker improves the native file system performance. The main negative is additional startup time for the initial file system sync to complete.
Windows encountered different issues in that the Docker native file system support does not support “inotify” events, plus issues with file permissions when new files are created. Inotify support is very useful for tools such as Grunt and Gulp. Currently Windows leverages Unify again, but this time synchronizing between the native Windows file system and the container. This was the best option found so far from a wide range of tested options.
Usage documentation will be released with Magento DevBox.
Who Should Try Magento DevBox?
We are interested in a range of developers trying out Magento DevBox from experts to developers completely new to Magento. The goal is to simplify development for all developers. The defaults are intended to be suitable for new developers, with more options available for experts.
One particular note is inclusion of Varnish. A very common problem that has become apparent is developers are not testing sufficiently with Varnish in place, resulting in issues only being detected at the end of a project when rolled to production. Developers are therefore encouraged to perform local development with Varnish enabled. One useful piece of feedback is whether Varnish should be enabled by default for all development as a base expectation.
Conclusions
Magento DevBox is going to launch as a public beta shortly. The goal is to collect wider community feedback before it becomes “official”.
One of the interesting future areas of exploration is we are also prototyping creation of training environments based on Magento DevBox. The goal is to have the same development environment available, but preloaded with a database and exercise files as a starting point for tutorials.
Alan Kent's Blog 
It looks like you just copied the idea from MGT-Commerce:
https://www.mgt-commerce.com/cms/mgt-development-environment
Thanks for dropping some feedback. No, if you have been following my blog you will see experiments in this area for a long time. We finally got around to picking a winner solution. But its hardly a novel idea. It just was not needed in M1 because tools like MAMP and WAMP did a good enough job. But once you say “you should use Varnish during development to make sure caching is right” or “I want to use RabbitMQ on my project” it starts getting too complicated to describe how to install on Mac, Windows, Linux etc. This is just about making it easier for developers to get an environment up covering the tools we think developers may need. (Oh, Gulp/Grunt I want to do a bit more thinking about. This is coming out as a beta to see what people like, what we should change.)
Thanks for sharing MGT’s solution, however it would be much better for the community if Magento was maintaining this, so that the best practices come directly from Magento engineers and are up to date faster with every new Magento release.
Shame Docker on Mac doesn’t run as well as other OSs.
Is gulp/grunt/node support baked into VM for developing on the front end?
I was under the impression unison wouldn’t play well with grunt/gulp watch processes due to the file system events which they watch for not firing the same when using this method.
Its good on Mac, but not perfect – it struggles with large numbers of files. But, its not perfect on Windows either – arguably worse. I am hopefully Docker team will continue to improve here. (It is a bit different to the more common Docker use case of managing production images etc. so I don’t really expect this to be #1 priority for the Docker team.)
Unison works well with Gulp/Grunt, which is why we want that way. Unison is just doing standard file I/O and so triggers iNotify events. Decent Gulp/Grunt support is part of why this took so long to find a combination we were happy with. The negative of Unison is mainly the startup time and the occasional hiccup. Otherwise for me it has been working surprisingly well.
Docker on OS X is definitely improving, though. I keep up with all updates and it runs quite well for me, no complaints.
When you say “Shortly” Can you elaborate? I would love to start playing with this 🙂
The code is fundamentally done, but a part of it is a online web interface that involves coordination with a different part of the org to get live. They have lots of other things on their list too. Feel free to reach out to Piotr directly, but my guess is “the next week or two”, but things always take longer than my optimistic expectations.
Is this the repository https://github.com/magento/magento2devbox-web for Magento DevBox? If yes and as you mentioned light weight container then I would suggest Alpine instead of Ubuntu. Please let me know your thoughts.
Is this the repository https://github.com/magento/magento2devbox-web for Magento DevBox? If yes and as you mentioned light weight container then I would suggest Alpine instead of Ubuntu. Please let me know your thoughts.
Production sites can value from super thin – but its less useful during development. Tools you want you keep find missing. This is why this is for development only, not production. Varnish, Redis, ElasticSearch etc however are separate containers in the current implementation – so if you don’t want them you don’t need them.
I mean, not having unnecessary things is good (to save memory and disk etc). Finding the right balance is hard and I suspect no clear “right” answer. But I did find in the past some super thin containers did not even have ‘vi’, ‘more’, or ‘less’. It was just too painful.
One question for me is whether we should be using NginX instead (or as well). I suspect so, especially for Magento Cloud users where NginX is used. Most of the Magento code does not care, but it is important for the whole project.
I totally agree with you super thin are for production point, if you don’t mind still as a side note docker’s philosophy is build, package and ship the same from Development to Production. Moreover, If I refer to your answer for the question above “Who Should Try Magento DevBox?” common problem about the Varnish, when you are suggesting enable Varnish even during the development to avoid Caching issue surprises in the Production env. It is more reasonable to use the same setup of Docker even in Development that is super thin. Let me fork and try to see if I can do it on super thin even for develop development env (Just for fun).
Regarding Nginx: Some of my thought and experiences are bundling Nginx and PHP-FPM as one container is preferable to over come file ownership and permission issues. However, if someone most expert in dealing the permissions the suggest to go with independent containers. To answer your question Nginx is more reasonable for considering as Webserver than Apache.
Thanks for the comments. I understand “if you are doing a docker project, there is advantage of using the same images all the way through.” This is not such a project. There is not a single standard production setup, and frequently with hosting solutions like GoDaddy you deploy code, not Docker containers. So a project providing product Docker containers may recommend using their containers for development as well – and it would make sense.
This project was “build a good development environment”. It just happens to use Docker. The native file sharing seemed ahead of Vagrant, VirtualBox etc – unfortunately ahead, but not yet “great”. So we are not focussing on Docker. And yes, I get lots of comments from Docker people “you are doing it wrong”. But I have done lots of experiments there for a year or two now. Docker is not our objective – its just a convenient tool. We are focussing on what fits Magento best.
Totally understood, I heavily use Dockers for Magento Development environment, experimenting on new extension/module building and continues unit testing. I am glad to see your efforts in bringing Magento DevBox, this is a great move over other tools available to spin up Magento Instance for Development. I will follow the repository and try to contribute wherever it is possible.
+1 for NGINX
There is a GitHub issue tracker – that would be the best place to leave comments so they don’t get lost. It will connect more directly with the real engineers working on the project. (I dabble, they build.)
Alan Kent, would definitely love to try. We’ve been using mgt-commerce, but their implementation is not complete (need manual adding redis, solr, elastic-search, etc). Please do let me know if you want us to try out and definitely when it is out.
In case you did not notice, its out. Its on the magento.com/download page.
Yup already on it.
We’re using Docker for a while now for Magento2 development. One of the best performance boosts we got was to store the folders /vendor and /var inside a data volume instead of on the host. Since these folders are on .gitignore, they don’t have to be stored on the host. Although we rsync some subfolders of /vendor to the host when we start the Docker containers, to make it easier to look into the source code.
With this setup we have acceptable performance with Docker for Mac and outstanding performance with dinghy/docker-machine.
Why just not to use sshfs on osx? It should work well, is platform in-depended, can be later easily pointed to the real hosting env…
We tried quite a few approaches. I have not tried sshfs, but have tried NFS and it was just too slow with PHP Storm. It does full file system scans periodically to index file contents, and the number of Magento files means the file system slow down is too painful.
Also I personally prefer the files on my native file system so if the container goes crazy I don’t care – my files are safe on my laptop. I can blow away the containers and start again any time I like.
apache? with php-fpm? very, very strange choice.
Feel free to leave suggestions in the GitHub issue tracker for the project. We wanted to get what we had going out and collect feedback rather than continue behind closed doors. It works, but happy to build it up from here. E.g. NginX is an obvious question – should we have that as an option as well / instead.
https://magento.com/blog/technical/set-your-magento-2-development-environment-faster
How I create a connection with MySQL Workbench ? I try to get the ip of the container or find it on configuration docker file but i cant find it.
I would try https://github.com/magento/magento2devbox-web/issues – I don’t have practical experience with MySQL workbench so I would be guessing.
You can connect to the container by localhost with the port generated by docker, the port can be checked by the command “docker ps”. You find the db container and you will see something like that “0.0.0.0:32768->3306/tcp”. Then you can use localhost with port 32768 for the connection
Does the m2devbox-unison-sync.bat file HAVE to remain open the entire time you work? Everytime I close it, things stop syncing… Is that the way it has to be?
Yes (unless you come up with a better way! ;-). I typically open up explorer, double click on the BAT file causing it to run in a separate window. Then to stop, I close the window. Nice simple way to start/stop synchronization, in a separate window I then minimize.
Thanks Alan, that’s fine with me – I just wondered if I was maybe doing it wrong. Would a short readme be of benefit? Or something in the DevDocs since they do mention the scripts in there already?
Alan, for developer that working on multiple Magento projects (i.e. agency like us), should we set it up so that each project running on each container? Or we use one container and keep changing the webroot of the project? (assuming we checkout our magento project files via git on separate folder on our machine)
I can talk theory, but would love real world feedback on this. I would go separate containers because of the database. Stop one set of containers and spin up the other one to switch between projects. (Otherwise you may run out of memory etc.)
Got it. Will continue to give you feedback.
E.g. NginX is an obvious question – should we have that as an option as well / instead. I try to get the ip of the container or find it on configuration docker file but i cant find it.
Hi Alan,
Quick behavioral query, since you’re the only person who I know who uses DevBox that would get back to me on it.
When you turn your computer off and back on again (or kill Docker for Windows and relaunch), do you have to manually restart db? (docker-compose restart db)
I run the m2devbox-reset.bat immediately after restarting computer but it only fixes half the issue. Seems that it needs to also restart db container?
Maybe that’s a bug though.. It has about 5 different issues raised it in the GitHub issue tracker so maybe it’s normal?
Sounds like possibly a bug. I want to try it out to see. We have some reorg in flight going on (rebalancing work between Kiev and Austin teams), so DevBox is being moved to another team as a part of that realignment causing some delays – combined with 2.2 focus. Not an excuse, just an explanation for delays. I am hoping once settled the DevBox team and accelerate progress on the reported issues. (I am hoping our DevOps team can take it up, to get better alignment with CICD and deployment pipeline etc. We just got to make sure they are staffed to right level with all their new obligations.)
Hi Alan,
Quick query – How does one get a proper hostname for DevBox Beta?
At the moment it is http://127.0.0.1:32774 for example. I’d like it to use http://www.mysite.dev
Is that possible? I only ask because I think the url might be breaking minicart template override in DevBox Beta and a proper hostname would probably fix it.
As a bit of background, all I did was override the minicart.phtml template by putting the original code in Magento_Checkout/templates/cart/minicart.phtml and then the JavaScript seems to act up. The code in minicart template is the exact same code copy/pasted from app/code/Magento/Checkout/view/frontend/templates/cart/minicart.phtml so it’s a bit odd. Removing the template from the theme’s template folder then resolves the issue, so it’s definitely breaking when overriding minicart.phtml, even with the original code.
This issue pretty much illustrates the issue: https://github.com/magento/magento2/issues/8461
And the comment from zamson is what makes me think it might be DevBox Beta’s url instead of hostname that’s breaking overriding the minicart template?
Have you tried editing your local hosts file to add in the host name as an alias for 127.0.0.1?
Hi Alan,
I have many times and to no avail I’m afraid. I ended up putting it down to a limitation of Docker. Unless, have you actually achieved it yourself?
My hosts entry is as follows:
127.0.0.1:32774 mysite.dev http://www.mysite.dev
The port is set in the docker-compose.yml:
ports:
– “32774:80”
Ah, nevermind – I removed the port. Alas, it does not fix the minicart.phtml templating issue but I guess that’s just something I’ll have to raise in the Magento issue tracker. Thanks
Sorry, I don’t have deep knowledge of that code. The issue tracker is more likely to reach the expert in the area.
Your Magento staff have apparently left this project to wither on the vine. No commits since March, and the master branch is broken and cannot build. Can you either get someone at Magento to fix it, provide an alternative, or at least mark the project as unmaintained.
We are trying to work out the resourcing going forward with the rebalancing of staff between the Kiev and Austin offices. So yes, unfortunately its a bit of an orphan at present. It is being talked about internally, but I don’t have a concrete answer yet. It will probably take second place to getting 2.2 out the door.
Hi Alan, this may well become the deciding factor with us going with Magento or not – is there truly no direction internally with regard to supporting a docker development solution?
I think the question is more which team is going to own it. I expect it to be resolved in the next week or so. Note that there are many other development environments that the community have put together (including a Vagrant environment https://github.com/paliarush/magento2-vagrant-for-developers and MageScotch https://github.com/joshuaswarren/magescotch).
I installed Magento devbox and i was able to open the Magento store and admin site. Suddenly after few days i am getting below error when i try to access the Magento site using browser (http://127.0.0.1:32775/)
SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3 Protocol mismatch.
I am able to see the html published from within the container by using cat http://127.0.0.1
Looking for solutions to resolve the problem
Maybe we need a new devbox with newer ssl patches ? I have not seen that begore
Hi Alan,
Any news on when DevBox might be re-released? Can’t download it at the moment, it’s been removed 😦
I think you’re one of the few people that might be able to provide a timeframe!
I am experimenting with a variation at https://github.com/alankent/magento2devbox-skeleton if you ant to be a beta tester. It is an experiment still is my only warning, but it fundamentally works.
Note – completely untested on Mac yet! I have windows laptop. But I think it should be close. Pull requests welcome!
Isn’t DevBox pretty much unsupported now? It hasn’t been updated for a looong time. Do you have any feedback for us on what the plans are for that yet?
Hi Charles, I am not at Magento any more so cannot speak for their plans. This post is quite old now (in computing terms anyway!)
Oh I guess I was the last to know about the move… ha ha. In the meantime, just want to thank you for what you did at Magento. Sure enjoyed reading your Magento-related blogs. Not a common thing for people in your position… gave us some great down-to-earth insights instead of the immaculately curated content of most companies. Keep it up where you’re at and congrats on the move.
Such a shame devbox is dead and not a goal for Magento to push for it and make dev life easier.
P.S. I also enjoyed following your blog for insights into the Magento “path to be”
Thanks. I agree. Argued for it internally, but upper management decided it was not worth the effort. There are community efforts instead, and who knows – they may have new plans with the Adobe acquisition, cloud, etc.
I did have a project on my GitHub account, but I have not touched it in a year now, so no idea if it still works with latest code etc. There was a README with instructions. Feel free to fork it and take it over if any use!
there’s no documentation and no devbox beta i can found on magento website.
is devbox discontinued?
Seems likely. There are a few community projects around, including some native (non-docker) solutions that seemed pretty good.