Chambers understand premises decisions better than most businesses: rent a serviced office, take a managed floor in someone else’s tower, or buy the building and hire the staff to run it. The same three-way choice faces any organization that runs its software delivery on GitLab, and the comparison deserves the same hard-headed treatment. GitLabOps — the craft of operating delivery on GitLab, carrying a descriptive name The Ops Atlas coined for it, with no official standard behind it — changes character entirely depending on which premises you occupy, because most of the work in this craft is premises work. What follows is the comparison in full, duties included, duties being the part brochures tend to omit.
The Serviced Office: GitLab.com
The hosted option is the serviced office: walk in, plug in, and the building management handles power, security, and maintenance. Version upgrades arrive without a decision; capacity scales without a requisition. The trade is control — configuration boundaries are the landlord’s, not yours. For a single small team, the Atlas’s guidance is direct: keep the operating discipline light, because the platform work you would otherwise do has already been done. A firm of this size should spend its attention on its practice, not on a delivery platform. The honest caveat is mobility: should the tenancy ever end, the export conversation is worth having before it is needed, not during.
The Managed Floor: GitLab Dedicated
Dedicated is the managed floor in someone else’s tower: your tenancy is isolated, the infrastructure is managed for you, and the lease terms are stricter than the open-plan arrangement. Where the serviced office houses many strangers under one roof, the managed floor is walled off — same building, separate entry, separate controls.
Isolation brings the compliance story many regulated organizations want, while leaving the maintenance burden with the landlord. It suits tenants whose requirement is separation with a service level, not root access. The premium buys a narrower argument with auditors: isolation is contractual, evidenced, and someone else loses sleep over the infrastructure side of it. The duties you retain are tenancy duties — how your side configures and uses the platform — rather than building duties.
The Owned Building: Self-Managed GitLab
Self-managed is the deed in your name, and every duty that follows from it. Upgrades run on your calendar, and the Atlas’s cadence advice is concrete: every one to two months, in order, pausing at the mandatory stopping points within each release series and waiting for background migrations to run to completion before moving on. Capacity is your survey; backups are your insurance policy, and an untested restore is uninsured. None of these duties is difficult in isolation, which is precisely the trap — they are easy individually and ruinous cumulatively when nobody is assigned to them. The Atlas puts rough numbers on where this becomes rational: roughly two thousand users is where a standalone installation begins to pay its way, and high-availability configurations enter the conversation nearer three thousand. Below those figures, owning the building usually means paying building prices for a tenancy’s worth of use.
Reading a Vendor’s GitLabOps Answers
Firms that hire vendors to run software face this comparison indirectly, and four questions cut through most sales conversations:
- Where does the platform actually run, and who holds administrative keys?
- Who may deploy to production, and what record proves each approval?
- How far behind current releases does the installation drift, and on whose calendar are upgrades?
- If the arrangement ends tomorrow, what is exported, in what format, and who pays for the move?
Answers that are specific and written down indicate a tenant of any model worth retaining. Evasions indicate a premises problem, whatever the brochure says.
Side by Side, Without the Sales Talk
- Control — hosted gives boundaries; dedicated gives isolation; self-managed gives the keys and everything the keys imply.
- Upkeep — none for the tenant on hosted, little on dedicated, a standing department on self-managed.
- Sizing logic — hosted fits small teams; dedicated fits isolation requirements; self-managed fits scale, from roughly two thousand users upward.
- Failure ownership — on self-managed, every outage question begins with you, which is either autonomy or exposure depending on staffing.
- Exit path — the easier it was to move in, the easier the move out; factor the leaving as carefully as the arriving.
Scoring the GitLabOps Premises Decision
When the choice is close, the Atlas recommends scoring candidate strategies against weighted criteria rather than debating tastes — an approach borrowed, deliberately, from how serious procurement decisions are made elsewhere. The method is unglamorous and settles arguments that opinions never do. One worked example shows why: a team evaluating a Docker Autoscaler fleet arrangement recorded 3.85; when its private-network requirement later vanished, the identical exercise scored hosted runners at 4.30, and the team switched without ceremony. The lesson generalizes to premises: write the criteria — compliance isolation, staffing reality, scale trajectory, cost per successful pipeline — weight them before anyone falls in love with an option, and re-score when constraints move rather than defending a stale score out of sunk cost. Investment in the wider discipline follows the same logic: it earns its cost once several teams share one platform, once the premises are self-managed, or once CI spending warrants an audit — and should stay deliberately light outside those conditions. The Atlas’s GitLabOps documentation documents the scoring method and the hosting trade-offs in full. The wider discipline follows the premises: fleet design, secret handling, and measurement matter in all three models, but their depth should match the duties retained. Choose the way chambers always have: by the duties you are genuinely prepared to carry, not by the view from the window.
