{"id":943,"date":"2026-10-27T15:10:00","date_gmt":"2026-10-27T15:10:00","guid":{"rendered":"https:\/\/charterkings.com\/blog\/?p=943"},"modified":"2026-10-27T15:10:00","modified_gmt":"2026-10-27T15:10:00","slug":"gitlabops-charter-season-case","status":"publish","type":"post","link":"https:\/\/charterkings.com\/blog\/gitlabops-charter-season-case\/","title":{"rendered":"GitLabOps Before Peak Season: A Charter Team Story"},"content":{"rendered":"

Every December, Meridian Charter \u2014 a fictional but very typical operator \u2014 watched its booking platform sweat. Flight requests doubled, guests booked helicopters and yachts from three time zones, and the small tech team braced for the season the way flight crews do: with a service campaign. This year, their operations lead Dana borrowed a frame from GitLabOps<\/strong>, the Ops Atlas’s name for running delivery on GitLab, and treated the platform like an aircraft entering a heavy check. Four checks, one week, no new hires. The stakes were blunt: last season a hung deploy had cost them a weekend of rebookings and an apology email they still cringe about. The story of that week is the most transferable thing we have published about small platform teams, so settle in.<\/p>\n

The GitLabOps Equivalent of a Pre-Season Service<\/h2>\n

Dana’s insight was that peak season punishes borrowed trust. Any system that works on an average Tuesday collapses under December load unless its assumptions hold. So the team examined four assumptions, one per day, and wrote down what each check found \u2014 findings first, blame never. The discipline of writing findings down turned out to matter as much as the fixes, because six months later the document still answers questions nobody remembers asking.<\/p>\n

Check One: Who Gets a Machine?<\/h3>\n

The Tuesday finding: every build job, trusted or not, could land on the same long-lived servers, and at least one job ran with shell access \u2014 a machine shared like a crew layover lounge. Anything a sensitive job left behind was readable by whatever came next. The fix made runners honest: delicate work now runs on ephemeral machines that exist for exactly one task and are destroyed afterward, set to a max_use_count of one. Shell executors were barred from anything untrusted, permanently, with the reasoning recorded in the same document that lists every runner and its purpose. If a guest charter never reuses linens between parties, why should a build machine carry one job’s leftovers into the next? Scrubbing sounds cheaper until you price the audit trail a wiped machine gives you for free: nothing to scrub, nothing to prove.<\/p>\n

Check Two: Who Carries the Keys?<\/h3>\n

Wednesday’s audit found cloud credentials in CI variables with the lifespan of fine wine. One dated from a vendor trial two years gone. The team replaced every long-lived key with OIDC identity tokens \u2014 short-lived, cloud-verified passes that expire before anyone can misuse them \u2014 and switched on the job-token allowlist so only listed projects can talk to the booking platform’s repositories. The deploy job alone receives identity tokens, so nothing else can impersonate it. Dana’s rule for the team now: a credential that outlives its job is not a convenience, it is an incident on layaway.<\/p>\n

Check Three: Who Can Touch Production?<\/h3>\n

Thursday was the uncomfortable one. Anyone with developer access could, in principle, push a change all the way to the booking system guests actually use. The team closed that door properly: production became a protected environment with named approvers, the production container tag was marked protected so only maintainers may push it, and deploy jobs were serialized so two releases cannot shove each other at the gate. Guests will never see this work, which is precisely the point \u2014 luxury is invisible reliability. The team rehearsed the approval path twice, so the first real December deploy would not be the first time anyone pressed the buttons.<\/p>\n

Check Four: What Does the Season Cost?<\/h3>\n

Friday was arithmetic. The team computed cost per successful pipeline \u2014 spend divided by green builds, not attempts \u2014 and discovered their smartest-looking choice, a Kubernetes executor fleet for everything, was quietly the priciest line item. The assumption that Kubernetes execution is always cheaper did not survive contact with their actual workload profile. Some jobs moved to simpler runners; the savings paid for the ephemeral fleet from check one. Measuring the right thing turned two arguments into one spreadsheet. The bigger lesson stuck: every cost assumption gets re-tested each quarter, because workloads drift and yesterday’s bargain quietly becomes this quarter’s line item.<\/p>\n

GitLabOps Habits Meridian Kept<\/h2>\n

Peak season arrived, bookings flowed, and the platform yawned through the whole thing. The service checklist that made that possible now hangs, laminated, in the team’s channel:<\/p>\n