Ask anyone at a launch facility what actually gets a spacecraft to orbit, and they will rarely mention the rocket first. Ground stations track it, ranging crews calibrate it, and written procedures decide who flips each switch. Software teams that build on GitLab live inside a similar arrangement, and GitLabOps has become the shorthand for it: the day-to-day work of writing pipelines, tending the machines that run them, and controlling what reaches users. The name comes from The Ops Atlas, which uses it as a vendor-specific label rather than an industry standard, so do not expect to find it on a certificate. What you will find is a craft with its own vocabulary, and this primer gathers the words a newcomer meets first.
What GitLabOps Actually Covers
Strip away the jargon and the work sits in four loops that repeat on every project. The configuration loop turns YAML files and shared components into a pipeline graph. The scheduling loop hands each job to a runner whose tags match. The delivery loop moves builds into environments until they reach users. The platform loop keeps the GitLab installation itself alive, with current versions, spare capacity, and backups that restore. Each loop has a signature failure: duplicated or invalid YAML in the first, jobs parked forever in the second, deployments nobody approved in the third, and API errors or a sluggish Gitaly in the fourth. When something breaks, asking which loop snapped is usually the fastest way to a fix.
A Mini-Glossary for First-Time Flyers
Before your first pass through the documentation, these are the terms worth keeping in a pocket notebook. None of them will appear on a news broadcast, yet each one names a piece of equipment a mission cannot fly without, and crew members who confuse two of them tend to file tickets against the wrong subsystem.
- Pipeline — the whole flight plan: a graph of jobs that build, test, and ship your code once triggered.
- .gitlab-ci.yml — the file where that plan is written. It lives in the repository, so changes ride along with code review.
- Runner — a ground station for jobs. It is a machine that picks up work, runs it, and reports back.
- Tag — a label on a runner. A job asking for the tag docker will only launch from a runner wearing it.
- Executor — how a runner runs a job: inside a container, on a virtual machine, or straight on the host.
- Environment — a named destination for a deployment, such as staging or production, with its own history and rules.
- Agent for Kubernetes — a slender link between GitLab and a cluster, used for deployments instead of broad, standing credentials.
- Artifact — a file a job leaves behind, such as a compiled bundle, so the next stage can pick it up without rebuilding.
- Protected environment — a destination where only chosen people and chosen branches are cleared to deploy. Think of it as a pad only rated crews may touch.
- Job token — the short-lived pass a job carries. Other projects decide whether to accept it, which keeps strangers out of your repository.
Why the Orbit Analogy Holds, and Where It Snaps
The scheduling loop deserves a closer look, because it produces the failure beginners meet first: a job stuck in pending with nothing visibly wrong. Nine times out of ten the job asked for a tag that no live runner carries, or every runner wearing that tag was busy, paused, or offline. The fix is usually a one-line change to the job or a nudge to the fleet, but diagnosing it teaches you more about how work gets assigned than any tour could.
Ground stations make a decent mental model for runners: both sit at fixed posts, listen for work, and only answer calls addressed to them. A satellite in a geostationary perch stays over one spot, the way a protected runner serves one sensitive project; if that idea is new to you, our plain-English explanation of geostationary orbits covers the physics behind the picture. Runners on ephemeral virtual machines behave more like something in a low pass, appearing briefly and burning up on reentry, and there is a beginner’s guide to low Earth orbit if you want the parallel spelled out. Even the middle case, an everyday Earth orbit for new learners, maps onto runners that serve several projects yet stay inside one trusted network. The analogy snaps at one point, though: orbits obey gravity and drift on their own, while a pipeline does exactly what the YAML says, every time, which is why sloppy configuration is the top source of surprises.
Where GitLabOps Ends and GitOps Begins
Newcomers often fold GitLabOps and GitOps into one idea, and the seam between them matters. A deployment job that runs a kubectl command is push-based: GitLab reaches out and moves the cluster. GitOps asks for something stricter, a declared state stored in a repository that an operator pulls and reconciles continuously. GitLab’s own guidance for production clusters points at Flux working alongside the agent for Kubernetes. None of this makes one approach wrong; they simply answer different questions, and knowing which one you are doing keeps the blame for a bad deploy from landing on the wrong desk.
Starting Without Overwhelm
One small team on GitLab.com needs very little of this ceremony: a tidy pipeline, a couple of tagged runners, and protected environments on the important branches will carry you far. Heavier investment earns its keep once several teams share one instance, the installation is self-managed, or CI spending starts to sting. If you want a map of the whole territory before your first launch, The Ops Atlas keeps a full GitLabOps reference that gathers loops, playbooks, and metrics in one spot. Read it once, keep the glossary handy, and your first pipeline will feel less like a countdown and more like a checklist.