EXPERIMENTAL Windows support is experiment!
Enable experimental mode by running:
pack config experimental true
Before trying out builds for Windows images, we recommend following the Linux image tutorial under Getting Started. Don’t worry, you can still run it on a Windows OS if you need to – just make sure to enable Linux containers for Docker first.
When you’re done, head back here.
In order to produce Windows container images, ensure Windows container mode is enabled in your Docker settings (available only in Docker for Windows).
Then, building a Windows app using Cloud Native Buildpacks is nearly identical to building for Linux:
Not using Windows?
packcan build Windows apps using a remote Windows Docker by setting a
DOCKER_HOST. Learn more
Before we can start, we’ll want to match your Windows environment.
Type the following command in PowerShell:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Format-Table -Property ReleaseId, CurrentBuild
Select the output that best matches your environment:
Learn more about compatibility.
To build an app you must first decide which builder you’re going to use. A builder includes the buildpacks that will be used as well as the environment for building your app.
For this guide we’re going to use a sample builder,
Now we can build our app. For this example we’ll use our samples repo for simplicity.
# clone the repo git clone https://github.com/buildpacks/samples # change directory to samples cd samples # build the app pack build sample-app --path apps/aspnet --builder cnbs/sample-builder:dotnet-framework-1809 --trust-builder
TIP: The builder may take a few minutes to download on the first use.
TIP: If you don’t want to keep specifying a builder every time you build, you can set it as your default builder by running
pack config default-builder <BUILDER>.
docker run --rm -it -p 8080:80 sample-app
The app should now be running and accessible via localhost:8080
pack and your source code don’t need to be on the same machine as your Docker daemon, thanks to support for the
DOCKER_HOST environment variable.
Essentially, this points your local Docker client (e.g.
pack CLI) to a remote Docker daemon. For instance, if the IP address of your host is
10.0.0.1 and its daemon is listening on port
2375, you can set
tcp://10.0.0.1:2375. Any subsequent
docker commands would communicate with the daemon on that machine instead of a local daemon.
This can be used to make
pack build Windows container images, as long as your remote Docker host is configured to support them (i.e. the host runs a Windows OS, has Windows container mode enabled).
Here’s an example where
pack on a Linux/MacOS machine can access a Windows 10 machine with Docker Desktop, using the localhost:2375 listener and the built-in OpenSSH Server.
# ssh port-forward for localhost:2375 to remote daemon ssh -f -N -L 2375:127.0.0.1:2375 10.0.0.1 # set to your local forwarded port export DOCKER_HOST=tcp://localhost:2375 # build the app pack build sample-app --path samples/apps/aspnet --builder cnbs/sample-builder:dotnet-framework-1809 --trust-builder # run it docker run --rm -it -p 8080:80 sample-app # access your app on your remote docker host curl http://10.0.0.1:8080
NOTE: When setting
DOCKER_HOST, keep in mind:
- never expose an insecure Docker daemon to an untrusted network. Use SSH port forwarding or mTLS instead.
- any volumes mounted via
pack build --volume <volume> ...or
docker run --volume <volume> ...must exist on the docker host, not the client machine.
- any ports published via
docker run --publish <host-port>:<container-port> ...will be published on the docker host, not the client machine.