I develop primarily using Visual Studio on Windows. The problem is that after a while Windows gets bogged down and I'm faced with needing to reinstall Windows. Similarly switching to new machines is a problem.

Reinstalling Windows is painful because my development environment has a lot of dependencies (such as extra MSBuild configuration files, VS extensions, npm, Java etc). I don't imagine I'm alone in having a complex system, and setting it back up would probably take a day minimum.

I've not really used Docker, but in theory it sounds like I could setup my dev environment in a Windows Container and then just ship it around (eg. copy to my laptop, put in a new Windows install) and it should be painless.

Is what I'm describing possible? Are there any downsides, such as performance, reliability? Other gotchas?

  • I'm curious what you could be doing with a development environment that causes Windows to "get bogged down." Installing Node, VS, and some plugins shouldn't cause any problems.
    – neilsimp1
    Oct 11, 2017 at 12:00
  • @neilsimp1 you're right, but the reality is something more like 4 versions of VS, editors, paint tools, Android Studio, Netbeans, Office, CrashPlan, Git, TortoiseSVN, Fiddler, remote desktop, conferencing, skype, wireshark, vmware and on and on.
    – Jim W
    Oct 11, 2017 at 16:09
  • As a side-note, you should look into disk cloning utilities. You could install your OS + all the needed software and configure everything just right. Then make a clone of your disk and back it up somewhere. When you need to "reset" everything, just restore from that clone and you're done. There are many tools that can do this and in your situation it can save you dozens of hours :) . Oct 11, 2017 at 20:28

3 Answers 3


This is not an uncommon problem, but Docker isn't really the right tool to solve it. Containers in general (including Docker) are intended to provide an application runtime for a single process, such as a web server, not for a multi-process scenario such as a dev environment. In can be done, but isn't a very elegant solution.

A better (and more common) approach is to create VMs either through a traditional hypervisor such as VirtualBox or Hyper-V (since you're on Windows). A typical workflow is:

  • Find or create a base VM image based on your preferred OS flavor. This can be done directly with the installer ISO, or someone in your workplace may have one already.
  • Once the base image is built, add in all the dev tools and settings that you need. Snapshot or save this as a separate image.
  • Now you can run this image, RDP or remote into it, and work until you get to a point where you "get bogged down", and then just save off the files you need (commit to source control, etc.), then blow away the image and start again from either of the two snapshots/images you created. This can be done in seconds, vs. up to a day the old-fashioned way.
  • At any point along the line, create additional snapshots when you encounter situations that you might want to rollback to in order to reproduce a problem, etc.

Vagrant is also a fantastic tool for doing much of the above in a more structured manner.

A side benefit of all this is that you now have standardized environments that can be shared with your whole team, saving everyone the effort. This is especially great for quickly on-boarding new people.

Back to your original question, Docker isn't really intended for this, but if you had a small enough dev environment (say PHP on Linux), you could do it in a container, and the benefit would be a much smaller image (potentially under 100MB vs many GB for a Windows VM with virtual disk).


not in one docker container but yes in n docker containers.

While you could - theoretically - assemble your whole dev environment inside one single container, docker was not meant to do this.

Instead you should deploy each service into separate containers, using docker compose, managing your whole infrastructure in one single file, where each service will have its own logfile, userspace, networking, etc.

Let me give you an example, this is a draft of my docker-compose.yml

version: '2'

    build: myproxy
    container_name: ppproxy
      - "80:80"
      - "443:443"
      - /var/run/docker.sock:/tmp/docker.sock:ro
          - www.domain1.it
          - www.domain2.it
          - www.domain4.it

    build: mydb
      DB_USER: sdffdssdf
      DB_PASSWORD:  fdsfsdsdf
      DB_NAME: dbanme1
      DB_ENCODING: UTF-8    
      VIRTUAL_HOST: myhost1.net.lan
      VIRTUAL_PORT: 5432

    build: mydb
      DB_USER: ssdfsdfs
      DB_PASSWORD:  sffdssd
      DB_NAME: dbanme2
      DB_ENCODING: UTF-8    
      VIRTUAL_HOST: myhost2.net.lan
      VIRTUAL_PORT: 5432

    image: myimages/oldservice:v1.1
    container_name: www
    command: /bin/bash /root/launch
        VIRTUAL_HOST: www.domain1.it
        VIRTUAL_PORT: 80
      - 80
      - mydb1
      - mydb1
      - myws

    build: myjettycontainer
        HTTPS_METHOD: noredirect
        VIRTUAL_HOST: www.domain2.it
        VIRTUAL_PORT: 8080
      - 8080
      - mydb1
      - mydb2
      - myproxy
      - mypostfix

    image: catatnight/postfix
    container_name: mailer
      maildomain: domain1.it
      smtp_user: mymail:sfsfdfds
      - 25

There is an nginx proxy (myproxy), two similar postgres databases (mydb1 and 2), an old java web application server (www), a java jetty container that provides a rest web service and finally a very simple SMTP postfix container.

Everything starts up - usually :) - with docker-compose up, either on my dev machine or in production; log files are aggregated into one easy to read file and it is possible to replicate locally almost every functionality with the guarantee that, if it works on my laptop it will work.


I use VirtualBox VMs for this kind of thing.

The portability of having your dev environment in a container is handy, but the really nice thing is that I can snapshot the thing before any upgrade attempts, and if I screw it up, it's no problem to fall back and start again.

I also find it helpful to do this because I frequently work with multiple versions of things like Qt, and I don't feel like figuring out how to get the two versions to co-exist - instead, I just put them on different VMs and I don't have to worry about interactions because I installed something incorrectly.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.