GitlabCI is a simple example of how you can achieve: version control of your recipes versioning to include image hash and commit id build of associated container and push to a storage endpoint (or GitLab artifact) for a reproducible build workflow with Singularity containers. See https://gitlab.com/singularityhub/gitlab-ci for the current code base on GitLab. Why should this be managed via GitLab? GitLab, by way of easy integration with continuous integration, is an easy way to have a workflow set up where multiple people can collaborate on a container recipe, the recipe can be tested (with whatever testing you need), discussed in pull requests, and then finally pushed to be a GitLab artifact, to your storage of choice or to Singularity Registry. Why should I use this instead of a service? You could use a remote builder, but if you do the build in a continuous integration service you get complete control over it. This means everything from the version of Singularity to use, to the tests that you run for your container. You have a lot more freedom in the rate of building, and organization of your repository, because it's you that writes the configuration. Although the default would work for most, you can edit the build, setup, and circle configuration file in the .gitlabci folder to fit your needs. https://gitlab.com/singularityhub/gitlab-ci/-/tags/1.0.0