Managed Git Server

One operated source-control offering with GitLab, Gerrit, Gitea, and Forgejo platform options

Managed Git Server is a facilitated local-development and delivery-infrastructure offer, not four unrelated service propositions. Assistance helps teams choose and operate the right git platform option — GitLab, Gerrit, Gitea, or Forgejo — after confirming workflow fit, hosting location, identity model, runner requirements, backup expectations, support coverage, and evidence needs.

The selected option can run in a customer account, an Assistance-managed environment, an approved partner environment, dedicated physical infrastructure, Kubernetes, Local Private Cloud, or a hybrid model. Claims about data residency, compliance, recovery objectives, and support hours are made only for the assessed environment and must be backed by provider evidence, contracts, runbooks, and restore or monitoring proof.

Option comparison#

Option	Choose it when	Review model	CI/CD and runners	Operating weight
GitLab	The team wants source control, merge requests, CI/CD, packages, registry, security workflows, and policy in one UI	Merge requests with approvals, protected branches, code owners, status checks, and policies	Built-in GitLab CI/CD through registered GitLab Runners; external CI can integrate through APIs and webhooks	Broadest platform surface; requires explicit ownership for runners, storage, upgrades, licenses, backups
Gerrit	Code review governance, patch-set review, verification labels, and controlled submit paths are the core requirement	Change-based review with patch sets, labels, submit requirements, and explicit verification	External CI such as Jenkins, Zuul, Tekton, or custom adapters reports votes or labels back to Gerrit changes	Specialized review platform with plugin, permission, replication, and workflow-onboarding needs
Gitea	A lightweight private forge is enough for repositories, issues, pull requests, packages, and simple Actions flows	Pull requests, branches, reviews, issues, organizations, teams, and branch protections	Gitea Actions-compatible runners when enabled, or external CI through webhooks, tokens, and status reporting	Lower platform overhead; lighter enterprise governance and security workflow surface than GitLab
Forgejo	The team wants a lightweight Gitea-family forge with community-governed project direction	Gitea-like pull requests, repository collaboration, issues, teams, and branch protections	Forgejo Actions-compatible runners when enabled, or external CI through webhooks, tokens, and status reporting	Lightweight operations with release, governance, and compatibility choices reviewed during upgrades

Gitea and Forgejo are separate selectable options

Forgejo began as a soft fork of Gitea. They remain similar for many repository and pull-request workflows, but governance, release cadence, compatibility decisions, and community priorities can differ. Assistance treats them as separate platform options during selection and upgrade planning.

Selection criteria#

Requirement or constraint	Starting option	What Assistance validates before recommending it
Integrated DevSecOps platform	GitLab	Edition and license needs, runner topology, storage, registry/packages scope, security features, and admin capacity
Strict review gates before code lands	Gerrit	Patch-set workflow readiness, submit requirements, verification labels, plugin set, and developer onboarding
Simple self-hosted repositories and pull requests	Gitea or Forgejo	Repository scale, identity integration, backup coverage, Actions compatibility, and governance preference
Community-governed lightweight forge	Forgejo	Compatibility expectations, release policy, governance requirements, and migration path from Gitea-family systems
Existing GitLab estate needs an operator	GitLab	Current topology, backup posture, runner health, upgrade path, license ownership, and migration risk
Existing Gerrit review culture	Gerrit	Current version, plugins, permissions, CI adapters, replication, and project configuration
Cost-sensitive internal tooling	Gitea, Forgejo, or a small assessed GitLab/Gerrit	Runtime footprint, storage growth, support level, runner isolation, and whether lighter governance is acceptable
Regulated or regional hosting requirement	Any option after evidence review	Runtime, backups, logs, support access, subprocessors, contracts, provider attestations, and customer controls

Hosting and ownership boundaries#

Deployment model	Suitable options	Boundary to document
Customer cloud account	GitLab, Gerrit, Gitea, Forgejo	Customer owns the account, billing, provider relationship, and policy approval; Assistance operates the scoped platform components.
Assistance-managed environment	GitLab, Gerrit, Gitea, Forgejo	Assistance owns more of the runtime surface for the engagement; region, backups, subprocessors, support access, and evidence are agreed.
Approved partner-hosted environment	Usually GitLab; possible others by assessment	Partner claims must be verified against current contracts and evidence; Assistance coordinates the operated boundary where scoped.
Assistance-operated physical servers	Gitea, Forgejo, and smaller assessed GitLab/Gerrit environments	Useful for development, CI, internal repositories, and predictable workloads; not a blanket internet-scale production promise.
Kubernetes or existing platform cluster	GitLab, Gerrit, Gitea, Forgejo	Customer platform standards for storage, ingress, secrets, monitoring, GitOps, and cluster ownership must be clear.
Hybrid	Any option	Common when source control, runners, staging, and production deployments have different risk, cost, or network-control requirements.

CI/CD and runner implications#

Managed Git Server decisions affect runner security as much as repository hosting.

Option	Runner implication	Typical Assistance work
GitLab	GitLab jobs target group, project, protected, or tagged runners; caches, artifacts, environments, and deployment runners matter	Runner scope and tags, protected-runner rules, cache/artifact storage, queue monitoring, privileged-job separation
Gerrit	Gerrit emits events and expects external systems to verify changes; worker capacity is owned outside Gerrit	Event adapter ownership, verification labels, submit requirements, Jenkins/Zuul/Tekton integration, worker pool monitoring
Gitea	Gitea Actions-style workflows use configured runners and labels where enabled; external CI may still be simpler	Runner registration token handling, label contracts, private-network profiles, workflow smoke tests, compatibility findings
Forgejo	Forgejo Actions-style workflows use configured runners and labels where enabled; behavior depends on release and runner version	Runner registration token handling, trust-level labels, private-network profiles, workflow smoke tests, compatibility notes

Use Managed runners overview when builds need stronger isolation, predictable capacity, private-network access, local-development parity, or separation between general CI and production deployment jobs. Use Managed Mattermost when delivery, incident, and support communication should share the same customer-controlled local-development boundary.

Security, compliance, and regional hosting language#

Assistance can help collect and organize evidence for security, procurement, privacy, and compliance reviews. Assistance does not make blanket claims that every managed git server is EU-resident, GDPR-compliant, certified, or available 24/7.

For any platform option, confirm:

where the application, repositories, database, packages, artifacts, logs, and backups are stored;
who owns the cloud account, partner contract, DNS, email, monitoring, object storage, and runner infrastructure;
which providers and subprocessors can access the environment and under what approval path;
which certificates, audit summaries, DPAs, TOMs, backup reports, restore tests, and runbooks are current and in scope;
who owns user approvals, access reviews, data classification, repository retention, release decisions, and legal conclusions.

Prefer precise language such as "deployed in the agreed EU region when scoped and evidenced". Avoid unsupported claims such as "all customer data stays in the EU" unless runtime, backups, logs, support access, runner paths, and subprocessors are contractually confirmed.

Assistance recommendation process#

1. Workflow and evidence assessment#

We review repository count and size, users and groups, review expectations, branch model, CI/CD requirements, runner trust levels, identity provider, migration source, data-location drivers, compliance constraints, backup expectations, support hours, and current platform pain points.

2. Platform recommendation#

Assistance recommends GitLab, Gerrit, Gitea, Forgejo, or a staged migration path. The recommendation includes hosting model, responsibility split, upgrade policy, backup and restore approach, runner integration, monitoring signals, access boundaries, and support tier.

3. Build, migrate, or take over#

We provision the selected option, migrate repositories when scoped, configure identity, establish backup and monitoring baselines, connect runners or external CI, validate representative workflows, and document the operating boundary.

4. Operate and improve#

After go-live, Assistance operates the agreed platform scope, reviews incidents and capacity, schedules maintenance, refreshes evidence, and adjusts runner, access, or monitoring patterns as usage changes.

Option runbooks#

GitLab option runbook

Gerrit option runbook

Gitea option runbook

Forgejo option runbook

Managed Runners

Managed Mattermost

Managed Artifact Repositories

Getting started#

Request a managed git server assessment. We will compare GitLab, Gerrit, Gitea, and Forgejo against your workflow, hosting model, runner needs, identity requirements, evidence needs, and operating responsibilities before proposing scope.

Request git platform assessment →

Frequently asked questions#

Are GitLab, Gerrit, Gitea, and Forgejo separate Assistance services? No. They are selectable platform options under the managed git server offer. The option pages are runbooks that explain how each platform is operated when selected.

Is GitLab always the safest choice because it has the most features? No. GitLab is powerful, but its feature surface increases operational and governance responsibility. Smaller teams may be better served by Gitea or Forgejo, while strict change-review teams may need Gerrit.

Can runners be isolated by project or trust level? Yes. Runner isolation is part of the assessment. Assistance can separate general CI, privileged builds, production deployments, private-network jobs, and untrusted workloads when the support model includes runner operations.

Can we keep repositories in our own cloud or private network? Yes. Customer-cloud and private-network deployments are common when data location, compliance, billing, or connectivity requirements must remain under your control.