Scope: Access & provisioning, credits/usage, system setup, updates/releases. Last reviewed: 26 August 2026.

Access and provisioning

GitLab access is role- and scope-based: Reporter is read-only, Developer is the normal team-repository role, Maintainer is limited to cases requiring CI/CD administration, and Owner is assigned to Engineering Managers or Tech Leads for controlled groups/projects.

Corporate IT/admins provision platform licenses. AI Ops provisions citizen-developer repositories and normally grants Developer access; Maintainer access remains limited to AI Ops/platform owners. Temporary cross-team access should have an explicit expiration.

The company-managed GitLab organization is the required repository location for internal applications — personal repositories and unmanaged source storage are not permitted for these applications.

Credits and cost management

Internal license administration has included converting GitLab Duo licenses into standard GitLab licenses and later considering conversion into GitLab Duo Agent Platform credits. A renewal record documented converting 50 Duo licenses into 45 standard licenses with a $117.85 pricing difference — a transaction-specific figure, not a current license baseline.

GitLab Runner execution minutes may also affect production deployments, although teams may host their own runners. Corporate IT/admin ownership of licenses is referenced internally, but no current seat inventory, recurring chargeback model, or Runner-minute budget policy was found.

System setup

AI Ops-managed repositories use approved templates, protected main branches, CI/CD configuration, security checks, CODEOWNERS, repository documentation, and secret-handling controls. Citizen developers receive write access only to repositories they actively maintain; administrative access is restricted to AI Ops and approved platform administrators.

Repository ownership and lifecycle metadata are maintained through catalog-info.yaml and the company developer portal.

Updates and releases

Standard changes use feature branches and merge requests into protected main branches. Testing, QA, approvals, and CI checks precede merge or release. Deployable projects generally use semantic versioning and release tags; production promotion may require a manual gate.

Security-template or pipeline changes may have an adoption deadline. Procedures vary by repository, so each project should document its owner, release path, required checks, and rollback method.

Open items

Confirm the current license inventory, license owner, Runner-minute budget, deprovisioning workflow, and repository-independent release standard.