My company maintains five applications for many customers, and deployments are currently handled by copying build files to each customer's Windows server over Remote Desktop. I'd like to move to Docker-based deployments so releases can be built once, stored in a private container registry, and pulled by each customer's server through an automated pipeline.
I know managed options such as Azure Container Registry exist, but our customers use infrastructure from different providers, so I'm considering running the registry ourselves, similar to how Verdaccio can host private npm packages. Harbor, Zot, GitLab, Gitea, and the lightweight Docker Registry project are all possibilities.
Each customer should only be able to pull the applications they are authorized to use, so I'd need authentication, scoped permissions, and preferably audit logs. Most customer servers run Windows, and some of our applications are Windows-only. For applications that can run in containers, I was considering using Docker with WSL on those servers.
Does this deployment approach make sense? What self-hosted registry would you recommend, and are there important Windows-container or deployment issues I should address first?
4 Answers
The basic Docker Registry is the lightest self-hosted option if all you need is image storage and authentication. Harbor, GitLab, Gitea, and similar platforms add access control, scanning, project management, and audit features. For customer-specific permissions, Harbor projects and per-customer pull credentials are a practical pattern.
Self-hosting can work when customers are spread across different providers, but compare the operational cost with a managed registry first. A managed registry reduces patching, backups, availability, and security work. If you do run one yourself, protect it with TLS, use short-lived or narrowly scoped credentials where possible, back it up, and place image publishing and deployment behind a proper CI/CD pipeline instead of relying on Remote Desktop.
I would be cautious about requiring WSL on production customer servers. It adds another dependency and may be difficult to approve or maintain in some environments. Confirm whether the customer’s Windows version supports the container runtime you need, and consider using a supported Windows container runtime directly. The deployment process should ideally install and update the runtime automatically, pull a versioned image, perform health checks, and provide a rollback path.
Before choosing the registry, validate the Windows container strategy. Windows images are tied closely to the host build, so a container based on Windows Server 2022 may not run correctly with process isolation on a 2019 host. You may need separate image tags for each supported Windows version. Windows images are also much larger than Linux images, so download time and customer-site bandwidth could become the real deployment bottleneck.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures