I currently build Docker images on my local machine and push them to a self-hosted registry running on a VPS. I'm considering putting the build process on another VPS so it can pull the source code from a Git repository, build the images, and push them to the registry. The project is a side project, but I'm uneasy about placing the source code on an internet-hosted server and I'm unsure how much access the VPS provider might have. Is a remote build server a reasonable setup, or is it safer to keep building locally and only upload the finished images?
2 Answers
If you use a VPS, give the build process a read-only deploy key or token that can access only the required repository. Let it push to the registry with the smallest permissions possible, isolate the build account, and avoid storing long-lived secrets in the image or build logs. You can also use an ephemeral build environment and delete the checked-out source afterward, although deletion is not a guarantee against backups, caches, or a compromised host.
Remote builds are a normal way to deploy software, especially when using CI systems or dedicated build machines. The main question is your threat model: a VPS provider may have some ability to access the underlying host or storage, so you should not treat the server as fully private. For a side project without highly sensitive code, the practical risk is usually acceptable if the machine is hardened and kept up to date.
My main concern is simply putting the source code on a server controlled by a hosting provider. It’s only a side project, so I may be overestimating the risk.
Since the code is already in version control, a restricted read-only credential and a disposable build directory would be a reasonable compromise. For a more mature setup, a hosted CI service or self-hosted runner can handle the same workflow with clearer secret and build isolation.