Anonymized field note · September 2, 2026

Self-hosted forge or managed forge? The server bill is not the decision.

This qualitative case study draws from operating a small private GitLab-style instance and working in a managed GitHub-style organization. Names, hostnames, repository counts, people, clients, code, and security details are intentionally omitted.

What this is—and is not

It is an operator's comparison of ownership boundaries. It is not a performance benchmark, security rating, employer assessment, or claim that either environment represents every GitLab or GitHub deployment.

Four durable findings

Control is a job

The self-hosted forge kept repository data, configuration, identity choices, and upgrade timing under the operator's control. That control also created responsibility for TLS, mail, monitoring, backups, restore drills, upgrades, and capacity.

Managed does not mean operation-free

The managed forge removed the application-server maintenance. Repository policy, access review, Actions permissions, secrets, billing, and any self-hosted runners still needed owners.

Workflow consistency mattered more than the logo

Small merge requests, required checks, issue templates, protected branches, and a clear release path affected delivery more than whether the button said Merge Request or Pull Request.

External collaboration favored the public ecosystem

The managed public forge was easier for outside contributors, public releases, and existing integrations. The private forge was better when the boundary itself was the requirement.

The ownership worksheet

Question	Self-hosted points toward	Managed points toward
Who must control the application and data boundary?	Your organization	The platform under contract
Who owns upgrades and restores?	Your named operator	Platform for service; you for exported recovery and policy
Where do CI jobs run?	Usually your runners and network	Hosted or self-hosted runners; responsibility changes with the choice
Who needs to contribute?	A bounded internal group	Partners or a broad public developer ecosystem

The operational trap

A backup file is not a recovery capability. GitLab's current documentation requires configuration and secrets to be protected separately, and a restore generally requires the exact same GitLab version and edition. Upgrade paths may include required stops and background migrations. Those are real labor and testing costs.

Managed GitHub avoids that application lifecycle, but self-hosted Actions runners are still systems you deploy and maintain. GitHub explicitly assigns the runner machine's operating-system, software, and infrastructure cost to the customer.

Decision

Choose self-hosting for a named control, sovereignty, integration, or network requirement with a funded operator. Choose managed hosting when the repository forge is not your differentiator and the external ecosystem matters. In both cases, standardize the review and release workflow before arguing about features.

Primary references

GitLab self-managed backup responsibilities ↗GitLab restore prerequisites ↗GitLab required upgrade paths ↗GitHub self-hosted runner responsibilities ↗

See a sample decision report Compare my stack