# dockerfiles-windows: a library of base images for Windows containers > dockerfiles-windows collects Dockerfiles for Windows Containers across Windows 10 and Windows Server 2016, 1803 and 2019, with the images built automatically on AppVeyor and pushed to Docker Hub, and with directories named after specific upstream issues for the cases where a base image or a toolchain needed a workaround. It suits someone who has to ship a Windows container and would rather not start from a blank Dockerfile. **StefanScherer/dockerfiles-windows** — Various Dockerfiles for Windows Containers - Repository: https://github.com/StefanScherer/dockerfiles-windows - Stars: 1,127 · Forks: 391 - Language: JavaScript - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/stefanscherer-dockerfiles-windows ## What the repository is dockerfiles-windows is a collection of Dockerfiles for Windows, and the README says most of them can be run as Windows Containers on Windows 10, Windows Server 2016, Windows Server 1803 and Windows Server 2019. That list of runtimes is the key to understanding the project, because a Windows container image is tied to the exact build of the operating system it runs on. Unlike a Linux image, which is portable because the kernel is shared, a Windows image is bound to a host version and to a base image layer, and the images in this repository exist per version for that reason. The build is automated. Most of the Dockerfiles are automatically built on AppVeyor and pushed to Docker Hub, and the README points out that the badges appear in each subfolder's readme, so the build status of any individual image is visible without leaving that directory. The scale of the collection is worth noting. The repository has directories for apache, busybox, caddy, chocolatey, consul, curl, cygwin, diskspd, the docker cli, dotnet, dsc, elasticsearch, git for windows, golang, hugo, iis, iisnode, java, jenkins, mongo, msbuild, msys2, nanoserver, node in several variants, openssh, openssl, perl, php, portainer and more, along with a build script, a deployment script and a compose directory. The licence is MIT, the last push to the repository was on 2026-09-28, and the only release in the list is a single tag from 2017, which says more about how this project is distributed than the release list does. ## The base image problem, and the smaller images Two recommendations in the README are the most practically useful thing in it. For Windows Server 1803 the guide says it is recommended to use the smaller base images, and it names two of them, the nano server image and the server core image for that release. The same advice is repeated for Windows Server 2019 with the matching 1809 images. This is a size conversation that Linux users never have to have, and it exists because a Windows base image carries a large amount of the operating system, and the whole image is pushed and pulled over the network every time a container starts from a cold cache. A server core image is a smaller surface than a full desktop or full server image, and the difference shows up in a registry and on a slow link. The other recommendation is a directory called check-baseimage in the repository, and the name says what it is for. A base image check is the kind of thing you want when a build fails for a reason that is not your Dockerfile, and having a place in the repository that is dedicated to it is a reasonable structure for the community to use. The same reasoning shows up in the directory names elsewhere. There is a directory for long path support, one for getaddrinfo, one for a chown problem, and one for a network API helper, which are all the things that behave differently on Windows than a Linux developer expects. ## Getting a Windows host to run the containers The getting started section is organised per runtime, and it follows the same shape each time, because the shape is the difficulty. For Windows 10, you install the Docker Community Edition for Windows on a Pro or Enterprise machine, either on physical hardware or in a virtual machine. To get a virtual machine, the guide uses Packer with the packer-windows templates to build a Vagrant box named for the runtime, and Vagrant with a Vagrantfile that installs Docker for Windows along with a set of Docker tools, and then you clone this repository and create the images. For Windows Server 2016 the path is the same, with a box named for that release, and the guide adds an alternative, deploying a Windows Server 2016 VM to Azure with a template. The Vagrant command is given as vagrant up 2016. For 1803 and 2019 the instructions are the same shape and add a detail that changes the cost of the exercise. You need the ISO file from your MSDN subscription to build the box, which means the evaluation path for 2016 does not apply and you need a subscription. The Vagrant commands for the two later releases are given as vagrant up 1803 and vagrant up 2019, and in each case the README then tells you to clone the repository and create the images, and to look for the Dockerfiles with the matching suffix, the Dockerfile.1803 files and the Dockerfile.1809 files. So the tooling chain is Packer to build a Windows box, Vagrant to run it, and the repository to supply the images, and the naming of the Dockerfiles by version is what keeps the images tied to the right host build. ## The repository as a record of upstream problems Several directories in this repository are named after a specific issue rather than after a technology, and that is the most distinctive thing about it. There is a directory for a Compose issue numbered 5371, one for a Node issue numbered 8897, one for a go-winio issue numbered 67, one for a golang issue numbered 18555, one for a golang issue numbered 21867, and one for a git for windows issue. There is also a directory named after a CVE, CVE-2017-0290, which suggests the maintainer keeps the case around for reference rather than deleting it. Read as a whole, this is a decision to keep the evidence. A Windows container image is a moving target, because the base image changes and the toolchain inside it changes, and a Dockerfile that worked in 2017 may not build today. The issue named directories are where the maintainer put the reproductions and the workarounds for the cases that bit them, so that the next person with the same problem finds the answer in the same place as the Dockerfile. The project also carries a links document and a separate document of PowerShell tricks, and the README says that porting Dockerfiles from Linux to Windows was where PowerShell proved useful, with the tricks collected in that file. The feedback section is brief, saying that improvements, bug fixes, new Dockerfiles or more PowerShell tricks are welcome as pull requests, and that questions and problems can be opened as issues for discussion. ## PowerShell and the debugging script The PowerShell tricks section is short and the reason for it is stated plainly, that porting Dockerfiles from Linux to Windows was where PowerShell proved useful at some points. The repository has a dedicated document for that, and the top level also holds a build script and a deployment script, so the practical workflow of adding an image is a matter of writing the Dockerfile, building it and pushing it, all through scripts that are in the repository rather than in a wiki. The troubleshooting section points at the Microsoft documentation for Windows container problems, and then gives one command. ```powershell Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression ``` That is the container host diagnostic script, run from PowerShell. It is worth noticing what the command is doing, because it is the same shape as the install scripts people are told to run, a script fetched over the network and piped straight into an expression evaluator. In a trusted environment, on your own machine, with the URL from the vendor, that is a reasonable convenience. In a pipeline that runs it against an unverified copy, it is not, and the fact that this project documents the pattern in a troubleshooting section rather than hiding it is a point in its favour. The other Microsoft links in the further reading section cover the quick start for Windows Server containers with Docker, the networking behaviour including the Windows NAT limitations and the note that published ports on Windows containers do not do loopback, which is the kind of detail that costs an afternoon if you meet it unprepared. ## The state of the project and how to judge it The honest reading of the repository's state comes from the numbers. The single tagged release is from May 2017, while the last push to the repository was on 2026-09-28. That combination says the same thing it says for many container image repositories, which is that the artefacts are pushed to a registry on every build and the git tags are not the distribution channel. The README says the Dockerfiles are built automatically on AppVeyor and pushed to Docker Hub, and the per directory badges are the place to check whether that pipeline is still green for the image you care about. So the practical question is not when was the last release but which image do you need and does its build still pass. Two things are worth checking before you commit to it. The first is the runtime. The guidance is organised around Windows 10 and Server 2016, 1803 and 2019, and if you are on a newer server build you will be adapting a Dockerfile rather than using one, which is the work the repository was meant to save you. The second is the specific directories. For a general task, the images for node, dotnet, java, golang, nginx or similar are the obvious starting points, and they are the ones most likely to have been kept working. For an unusual case, the issue named directories and the check-baseimage directory are where the accumulated knowledge of this project actually lives, and they are more likely to be useful than the general advice. And the general advice is good. The packer-windows and Vagrant route removes almost all of the pain of getting a Windows host with a container runtime onto it, and the recommendation to use the smaller base images is the single decision that will save the most time and bandwidth. ## Conclusion Adopt dockerfiles-windows if you have to run a Windows container and you want a tested Dockerfile for your runtime rather than a blank one, because the images are built continuously and the directory names record the upstream issues that have bitten people. Do not adopt it if your target runtime has moved on, because the guidance is organised around 1803 and 2019 and the images are built for those. Before you build, read the PowerShell tricks file, since porting a Linux Dockerfile to Windows is where the time goes, and check the base image check directory for the runtime you are targeting. ## FAQ ### What does the dockerfiles-windows repository contain? It is a collection of Dockerfiles for Windows Containers, most of which can be run on Windows 10, Windows Server 2016, Windows Server 1803 and Windows Server 2019. The images are built automatically on AppVeyor and pushed to Docker Hub, with the build badges in each subfolder's readme. ### How do I get a Windows machine that can run these containers? The README's route is Packer with the packer-windows templates to build a Vagrant box for the runtime, and Vagrant with a Vagrantfile that installs Docker for Windows and the Docker tools, then vagrant up with the runtime number. For Windows 10 you can also install Docker Community Edition directly on a Pro or Enterprise machine. ### Which base images should I use on Windows Server? The README recommends the smaller base images, naming the nano server and server core images for the release you are targeting, for example the 1809 images for Windows Server 2019, and the 1803 images for Windows Server 1803. The smaller image matters because a Windows container image is pushed and pulled in full. ### Why are some directories in dockerfiles-windows named after issues? They hold the reproductions and workarounds for specific upstream problems, such as a Compose issue, a Node issue, two golang issues, a go-winio issue and a git for windows issue, plus one named after a CVE. Keeping them alongside the Dockerfiles means the accumulated knowledge travels with the images. ## Sources - [Issues](https://github.com/StefanScherer/dockerfiles-windows/issues) - [License: MIT](https://github.com/StefanScherer/dockerfiles-windows/blob/main/LICENSE) - [README](https://github.com/StefanScherer/dockerfiles-windows/blob/main/README.md) - [Releases](https://github.com/StefanScherer/dockerfiles-windows/releases) - [StefanScherer/dockerfiles-windows on GitHub](https://github.com/StefanScherer/dockerfiles-windows) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/stefanscherer-dockerfiles-windows