The most expensive word in a web team’s vocabulary is obviously. Obviously the pipeline file works the same on every project. Obviously the cluster route costs more. Obviously somebody somewhere certified this stuff. Every one of those sentences has cost a real team a real afternoon. The Ops Atlas calls the craft behind them GitLabOps — its own vendor-specific label for operating software delivery on GitLab, from pipeline files to runner fleets to the care of a self-managed installation — and because the label is young, folklore grew around it fast. Here are five beliefs worth retiring, and what to keep in their place.

Myth One: GitLabOps Is a Certification You Can Buy

Somebody will eventually offer you a course, a badge, maybe a laminated card. The name originates with The Ops Atlas, which coined it as a description of the craft, and as of late 2026 no industry body has defined it as a standard or a credential. That is not a scandal; it is just how young vocabulary behaves. Learn the underlying skills — pipeline design, fleet care, deployment governance — and skip the paperwork. Interviewers who probe for real ability ask how a stuck job was diagnosed, not whether a badge exists. A client who asks whether you are “certified” in it deserves an honest sentence about what the word actually names.

Myth Two: It Is Simply GitOps Wearing a Different Badge

The mix-up is understandable, since both words mention Git and both involve shipping. They answer different questions, though. A pipeline job that runs kubectl pushes changes into the cluster from outside. GitOps keeps a declared state in a repository and has a controller inside pull and reconcile it continuously, so the stored state is always the source of truth. GitLab’s own production guidance leans toward the pulled model, pairing Flux with the agent for Kubernetes. An agency can do the first on Monday and the second on Friday; just know which one you promised the client. Push is not forbidden — for a staging environment or a batch of static assets it is often the honest tool. The trouble starts when push becomes the production story, carrying a stored cluster credential that never expires and never explains itself.

Myth Three: One Runner Pool Fits Every Project

The temptation is real: one big pool of privileged machines, shared by every job, no tags to explain. The failure is equally real. Untrusted code — a fork, a first-time contributor, a dependency gone wrong — landing on the same machines that hold production access is how one bad job reads everyone’s secrets. Segregate the fleet by trust instead: protected runners for sensitive projects, disposable machines that serve one job each for everything uncertain. The pool is simpler to set up; the segregation is simpler to sleep behind. Tags are the mechanism: each machine advertises what it is cleared for, and each job states what it requires, so the match happens by declaration rather than by hope. When a job sits pending with no visible cause, the first question becomes “did anyone ask for a tag no machine carries?” — and that question has answered more support tickets than any log file.

Myth Four: Automatic Retries Heal Flaky Tests

Someone adds a retry to every job, the suite goes green, and the team celebrates. What actually happened is that the tests stopped being consulted. A blanket retry instructs the platform to re-run anything red until it turns green, which converts “this test caught a real problem” into “this test occasionally has opinions”. Retry settings belong on genuinely transient infrastructure trouble. Flaky tests deserve the harder treatment: being read, understood, and either fixed or deleted with intent.

Myth Five: Self-Managed Means Upgrading Whenever It’s Convenient

A self-hosted installation is a bit like a client’s WordPress core — nobody notices it until it is embarrassingly out of date, and then everything is urgent. The workable rhythm is an upgrade every month or two, walking through the required stopping points between versions rather than leaping over them, and letting background migrations finish before the next hop. Teams that leap accumulate a backlog that converts a Tuesday patch into a weekend project, with API errors and a sluggish Gitaly as the opening act. The stopping points exist because certain releases must be passed through in order — skip one and the data format changes arrive before the code that understands it. Calendar-driven patching sounds duller than leapfrogging, and it is; dull is what you want from an upgrade.

Keeping the Team’s GitLabOps Story Straight

Retries deserve one more paragraph, because the fix has a shape. When a test fails intermittently, resist the urge to automate around it. Re-run it in isolation, note whether it passes on a different machine, and check whether it shares resources with other tests. A test that only passes when it runs first is telling you about ordering, and a test that passes everywhere except on Fridays is telling you about the maintenance window. Both are fixable; neither is fixed by an automatic second attempt. Budget an hour a week for this hunting and the suite regains its authority within a month.

Keeping the Team’s GitLabOps Story Straight

Myths survive where documentation is silent, so write down what your team actually does: which executor serves which project, who approves a production deploy, when the instance last moved versions. The Atlas’s GitLabOps overview is a fair starting text for that conversation. Three questions expose most silent assumptions quickly:

• Which projects are allowed to run code on machines that can reach production?
• What stands between a green pipeline and a live deployment, and who can override it?
• If the person who configured the runners left tomorrow, could anyone reconstruct the setup?

Uncomfortable silences in that exercise are not failures of the exercise. They are the map of what to document next. And the habit generalizes — most website problems we see trace back to the same root cause of unwritten assumptions, which is why we keep preaching the discipline in our pre-development website planning walkthrough and our walkthrough of the essential pages every business site should include. Structure first, opinions second — in websites and in pipelines alike.