GitLab Runner

Why the cloudimg image

A runner image that carried a registration would hand every deployment the same identity, claiming jobs from, and streaming build logs back to, an instance belonging to somebody else; this image contains no registration, no runner token and no remembered address, and the service will not start until you connect it. Each instance also generates its own unique runner name on first boot, so two runners on one server never collide. Because a runner executes code from anyone who can push to the projects it serves, the boundaries around a job are set deliberately rather than left at their defaults: jobs get no access to the container engine, cannot mount host directories, cannot run privileged, and cannot reach the cloud instance metadata service where a machine identity would be handed out. The executor that would run job scripts directly on the machine is refused outright. The container engine comes from the distribution archive, and the runner's own package source is wired into automatic security updates rather than left to rot, so both keep being patched. An on instance self test runs a real pipeline job and reports back on every one of those boundaries. Paired deployment guide and 24/7 cloudimg support.