DevOps AcademyLearn the delivery system
Chapter 01Lesson 03~120 minutes

GitLab Platform Foundations: GitLab.com, Self-Managed, Dedicated, Tiers, and Architecture: Configuration, Design Choices, and Tradeoffs

Choose among GitLab offerings, ownership models, and subscription tiers by tracing operational responsibility, governance, data location, upgrade ownership, and cost rather than treating every GitLab deployment as equivalent.

ArchitectureGitLab.comSelf-ManagedDedicatedTradeoffs

Learning objectives

  • Separate offering choice from tier choice and explain why they answer different architecture questions.
  • Choose between a personal namespace and group-owned project based on governance and inheritance rather than convenience alone.
  • Compare SaaS convenience with Self-Managed control, upgrade/backup responsibility, and operational burden.
  • Label paid/Ultimate/Dedicated/admin-only capabilities as optional while preserving a complete Free learning path.
  • Use a decision matrix to justify maintainability, security, governance, reliability, compatibility, performance, and cost.

1. Architecture starts with responsibility, not feature count

“Which GitLab should we use?” is not one decision. It is at least three: offering (GitLab.com, Dedicated, Self-Managed), tier (Free, Premium, Ultimate), and namespace ownership (personal or group hierarchy). Collapsing them creates bad comparisons such as “Self-Managed is more secure” or “Ultimate means Dedicated.” Neither statement is generally correct.

Start with responsibilities: who operates the application and infrastructure; who controls upgrades; where data must reside; who needs administrator authority; what availability/recovery objective exists; and which platform capabilities are required. Then map those needs to current product offerings and tiers.

2. Offering responsibility matrix

Dimension GitLab.com GitLab Dedicated GitLab Self-Managed
Tenancy Multi-tenant SaaS. Single-tenant SaaS. Depends on your deployment architecture.
Underlying platform operation GitLab. GitLab, within Dedicated’s managed model. Your organization.
Customer admin boundary Namespace/project administration; no GitLab.com instance admin tools for customers. Tenant/application administration plus documented Switchboard controls; underlying environment access remains managed. Full Self-Managed administration subject to your infrastructure and product configuration.
Upgrade responsibility GitLab operates SaaS rollout. GitLab operates scheduled managed upgrades. Your organization plans and executes supported upgrades.
Backup/restore responsibility Service responsibility; customer still needs application-level continuity/export strategy appropriate to risk. Managed service model with Dedicated-specific controls. Your organization must design, perform, and verify backup/restore for relevant components.
Mandatory course path Yes: GitLab.com Free. No: architecture/read-only study only. No: administration chapters later use disposable/simulated paths.
Version awareness. At generation time, GitLab’s docs selector identifies 19.2 as the current release and 19.3 as upcoming. Self-Managed examples must use documentation matching the installed version; current GitLab.com behavior must not be projected backward onto an older instance.

3. Dedicated is not “Self-Managed in someone else’s cloud account”

GitLab Dedicated is documented as a fully managed, single-tenant SaaS offering. The customer has meaningful configuration and data-residency choices, but GitLab operates the underlying service. Dedicated administration also uses product-specific surfaces such as Switchboard. That is different from Self-Managed, where operators can own the installation, database/storage dependencies, backups, upgrades, and infrastructure troubleshooting.

This distinction matters during incidents. “Open the Rails console” might be a valid Self-Managed diagnostic in the correct context, but it is not a generic GitLab instruction and is outside the normal Dedicated customer boundary. Likewise, a GitLab.com user cannot access the instance Admin area merely because they are Owner of a group.

4. Personal namespace versus group-owned project

A personal namespace is excellent for a solo disposable lab because it minimizes governance complexity. A production team normally benefits from group ownership because groups organize membership and multiple projects, support subgroups, and allow settings/access to be governed at a shared namespace boundary.

Question Personal namespace Group namespace
Best fit Individual experiments, personal projects, simple Free labs. Teams, products, departments, shared governance.
Subgroups Not available beneath a personal namespace. Supported; useful for hierarchy and delegated administration.
Subscription on GitLab.com Paid subscription is not applied to a personal namespace. Subscription applies at the top-level group and flows to its hierarchy according to product rules.
Membership model Primarily project-specific collaboration around the user namespace. Group membership can grant access to projects in the hierarchy; inherited access must be understood.
Transfer consequence Moving a project can change URL/path and governance context; inspect permissions, integrations, CI variables, registries, and references before production transfers.

5. Free, Premium, Ultimate: treat entitlements as current policy

Tier selection should begin with a requirement that can be stated independently of GitLab marketing: for example, “we require a particular merge approval control across private projects” or “we require a specific security scanner/policy.” Then verify the current feature page for tier, offering, version, and prerequisites.

Do not reverse the reasoning by buying a tier and then inventing a reason to use every feature. Also do not teach a paid feature as if it were universally present. The academy’s mandatory path remains Free; gated features are optional tours, fixtures, or policy exercises until a later chapter genuinely needs them.

6. Keep seven boundaries separate

  1. Git: commits, refs, merges, remotes.
  2. GitLab application: projects, groups, MRs, issues/work items, settings, roles.
  3. GitLab CI/CD: pipeline creation, jobs, variables, environments, artifacts.
  4. Runner/executor: where untrusted or trusted job code actually executes.
  5. Registry: package/image identity, permissions, retention, distribution.
  6. External systems: cloud, Kubernetes, IdP, external registries, deployment targets.
  7. Self-Managed/Dedicated administration: platform lifecycle and infrastructure controls appropriate to the offering.

Every later chapter becomes easier if these are not blended into “the GitLab server.”

7. Worked design scenario

Assume a six-person platform team is building an internal service. They need shared ownership, several related repositories, normal merge-request collaboration, small CI jobs, and no regulatory requirement for private tenancy. They do not want to operate GitLab infrastructure.

A defensible starting design is GitLab.com with a group-owned namespace. Start on the Free path if required capabilities fit; verify any gated requirement before upgrading. A personal namespace would weaken shared organizational ownership. Self-Managed would introduce upgrade, backup, monitoring, storage, and recovery responsibilities without a stated requirement. Dedicated would introduce enterprise cost/contract complexity without a stated single-tenant/regulatory need.

Key point: this recommendation changes if requirements change. Data-residency, isolation, administrator access, regulatory controls, latency/networking, integration boundaries, or existing platform operations can move the result.

8. Decision worksheet

Criterion Question to answer Evidence
Maintainability Who patches/upgrades GitLab and its dependencies? Operating model + current supported upgrade docs.
Security Which party controls infrastructure; what isolation/data boundaries are required? Offering architecture + threat model.
Governance Where should ownership and inherited membership live? Namespace/group design.
Reliability Who owns HA, backup, restore verification, incident response? SLO/RPO/RTO and offering responsibilities.
Compatibility Which version/API/integration constraints exist? Versioned docs and integration support matrix.
Performance Are runner locality, repository size, network, or registry latency material? Measured workload characteristics.
Cost License/subscription + compute/storage + operator time? Current pricing/usage data; do not freeze into architecture docs.

9. Common design mistakes

  • “We need Self-Managed because we want private repositories.” Private project support is not the same question as infrastructure ownership.
  • “The Owner role means instance administrator.” Project/group ownership and instance administration are different scopes.
  • “Dedicated gives us shell/database control.” Dedicated is managed SaaS; customer controls are intentionally bounded.
  • “The UI has a menu, so the feature is included.” Verify the exact feature’s current tier/offering/version/prerequisites.
  • “Free is only for toy learning.” The course uses Free for the mandatory path because core Git/project/collaboration concepts can be learned without purchasing governance/security add-ons.

10. Design lab — choose without changing anything

Create a one-page architecture decision record for three fictional organizations: a two-person open-source project, a regulated enterprise requiring isolated managed SaaS, and a company with a mature infrastructure team that explicitly requires full instance administration. For each, choose an offering, namespace ownership model, starting tier assumption, and list three operational responsibilities.

Verification: each choice must cite a current official GitLab source for offering/tier facts and separately state assumptions. Cleanup: none; this lab creates no GitLab resources.

Knowledge check

A company needs a single-tenant managed GitLab service but does not want to operate the underlying infrastructure. Which offering is designed for that requirement?

Why can the same GitLab.com user encounter different paid features in two projects?

When is Self-Managed a poor default?

Does Owner on a project imply access to the GitLab.com Admin area?

Summary

Choose GitLab architecture by separating offering, tier, and namespace ownership. GitLab.com optimizes for SaaS convenience; Dedicated provides managed single-tenant SaaS; Self-Managed gives the organization platform lifecycle responsibility. Personal namespaces suit individual work; groups provide shared hierarchy and governance. Paid tiers are current product entitlements, not properties of Git or permanent facts.

Next lesson

Diagnose the layer before fixing the symptom

Lesson 4 turns these boundaries into a repeatable troubleshooting method and intentionally breaks safe assumptions so you can distinguish Git, GitLab, permission, tier, offering, and context failures.

Official references

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0Send only Ethereum/ERC-20 compatible assets to this address.