GitLab tells you what it's killing. Read that first.

Launches are what a company hopes will happen. Removals are what it has already decided.

That asymmetry is why GitLab is one of the most readable competitors in B2B software. It ships on a fixed monthly schedule, publishes a release post every time, and — unusually — announces what it intends to remove well before removing it. Most teams watching GitLab skim the headline features and move on. The more honest signal sits a few clicks away, in the list of things GitLab is giving up.

This teardown looks at three surfaces: the monthly release post, the deprecations and removals notices, and the tier badges stamped on the docs.

A fixed cadence makes silence measurable

GitLab releases monthly, and major versions — the ones allowed to carry breaking changes — land once a year. That predictability is a gift to anyone watching. When a company ships on a fixed rhythm, you stop asking whether something changed and start asking what moved inside a known window.

The release post itself is long and structured. Features are grouped by the product area they belong to, and each one carries a label for the plan it's available in. Read one release post and you learn a few features. Read six in a row and you learn which areas get investment month after month and which go quiet.

Quiet is the part people miss. A product area that showed up in every release for a year and then drops out for three consecutive months hasn't necessarily been abandoned. But something changed — a team was moved, a priority slipped, or the area reached "good enough." Any of those is useful to know if you compete there.

The deprecation list is a roadmap written in the past tense

GitLab keeps a public record of deprecations and planned removals in its docs, and its release posts call them out as well. Each notice typically names the feature, the version it was deprecated in, the version it will be removed in, and what users should move to instead.

That last field is the one to read slowly. "Use X instead" is GitLab telling you, in writing, which of its own products it now considers the real one. When an older feature is deprecated in favor of a newer one, the newer one is getting the engineering time, the docs attention, and eventually the sales pitch. If that newer feature overlaps with your product, the deprecation notice is effectively a launch date for a more serious competitor to you.

A few patterns worth noting as you read the list:

• Removals clustered in one product area. Several deprecations in the same area in a short window usually means a rebuild, not cleanup.
• Removals of self-managed-only behavior. These hint at where GitLab wants customers to run — and which deployment model it's optimizing for.
• Long gaps between deprecation and removal. A generous runway means GitLab expects pushback from large customers. Those customers may be the ones open to a conversation.

Deprecation notices also sidestep a problem we've written about before: a launch is not your roadmap. A launch is an intention. A scheduled removal is a commitment with a version number attached.

Tier badges show where the money line moves

Nearly every page in GitLab's documentation opens with a small badge: which tiers the feature is available in (Free, Premium, Ultimate) and which offerings it applies to (GitLab.com, self-managed, Dedicated). It's meant to save readers a trip to the pricing page. For a competitor, it's a packaging history.

When a feature's badge changes — say, from Ultimate-only to Premium and above — that's a pricing decision made without touching the pricing page. Moving something down a tier usually means it's become table stakes, or that a competitor forced the issue. Moving something up, or launching a new capability as Ultimate-only, tells you what GitLab thinks large buyers will pay extra for.

These shifts rarely get their own announcement. They show up as a one-line edit at the top of a docs page, which is exactly why they're easy to miss. It's the same reason competitor docs often leak roadmap signals faster than marketing does: docs get updated because they have to be accurate, not because someone wants attention.

What not to over-read

GitLab works in the open, and the volume of public material is enormous: issue trackers, merge requests, direction pages, handbook entries. It's tempting to treat all of it as intelligence. Most of it isn't. An open issue with a hundred upvotes is a request, not a plan. A direction page describes ambition, and ambition gets rewritten.

The three surfaces above are different because each one records a decision that has already been made: something shipped, something is scheduled to go, something changed tier. That's the filter worth keeping for any open company — and the lesson from PostHog's version of radical transparency applies here too. Visibility is not the same as signal.

The takeaway

If you only have time for one GitLab surface each month, skip the features and read what's being removed — then check what it's being replaced with.

That's also the kind of reading Seeto makes easier. It watches public pages like docs, changelogs, and pricing continuously and records each change as a discrete, dated event, so a tier badge that quietly moves from Ultimate to Premium shows up as an entry rather than a thing someone noticed by accident. What the move means for your packaging is still a call your team has to make.