We support five applications for many customers, and deployments are currently handled by copying build files to each customer's Windows server over remote desktop. This makes releases and updates difficult to manage. I'm considering packaging the applications as Docker images and hosting them in a private container registry on one of our own servers, similar to how Verdaccio can host private npm packages. A managed registry such as Azure Container Registry is also an option, but I'd prefer to self-host if it's practical. Most customer environments run Windows, although some applications are Windows-only and others could run in containers. My initial plan is to use Docker through WSL on the customer servers, pull the images from the registry, and run the services with Docker Compose. Does this sound reasonable, and which registry and deployment practices would you recommend?
5 Answers
If you already use a source-control and CI system, check whether it includes a container registry. That can give you one workflow for building images, scanning them, publishing releases, and letting customer environments pull specific versions instead of manually copying files.
The customer’s operating system doesn’t determine which registry you need. A self-hosted product such as Harbor, Nexus Repository, or a complete Git service with registry support can store your images, and the customer machines can pull the images they need. Use Dockerfiles to build the images and Docker Compose to define and run a group of related services. Just make sure every image is built for the correct CPU architecture and that the registry is secured with TLS and per-customer credentials.
A managed registry is usually the safer choice for production deployments. You can create separate credentials for each customer and have their servers pull only the repositories they need. Use immutable version tags, or preferably deploy by image digest, so a release cannot silently change underneath a running installation. Self-hosting works, but you become responsible for backups, upgrades, certificates, storage, access control, and keeping the registry available.
The general plan is workable, but Windows needs a little extra care. Linux containers normally run through Docker’s Linux backend, commonly using WSL2, while Windows containers require compatible Windows container hosts and matching base images. Confirm that each customer server supports the required Docker mode, virtualization, WSL2 configuration, networking, persistent volumes, and automatic startup. For applications that are Windows-only, containers may not be a straightforward replacement for a native Windows deployment.
A Git service with built-in CI/CD and an image registry can also cover the whole process: commit code, build and test the image, publish it, then deploy a selected version to each customer. Keep the registry private and avoid making production systems depend on a floating tag such as latest. Pinning versions makes rollbacks much easier.
That is close to what I’m looking for. Having the build pipeline publish the image and then deploying a pinned version would be much cleaner than transferring build folders manually.
Also test the complete installation on a clean customer machine before rolling it out. WSL2, firewall rules, service startup, volume permissions, and proxy settings can differ significantly between Windows environments.