Alternativen im Vergleich: Codeberg, Forgejo, Gogs, Launchpad und mehr

Teil 2 einer dreiteiligen Serie zu GitHub-Alternativen.

Wer beim Plattformwechsel zuerst auf den Hosting-Standort schaut, sucht nach dem falschen Kriterium. Entscheidender ist, wer die Defaults setzt — und ob KI-Features in der Architektur überhaupt vorgesehen sind. Dieser zweite Teil sortiert die ernstzunehmenden Alternativen entlang dieser Linie.

Nachdem Teil 1 den Anlass beschrieben hat — Default-on-Trainingsnutzung ab dem 24. April 2026 für individuelle Copilot-Konten —, lautet die Anschlussfrage: Wo gibt es das Gegenteil? Eine Plattform, die in der anderen Richtung gebaut ist, idealerweise per Architektur, nicht per Toggle. Die Antwort hängt weniger an Geographie und Hostingprovider als an einer einfachen Eigenschaft: Wer entscheidet, was nach außen abfließt?

Vier Tiers nach Kontrolle über Defaults

Sinnvoll ist eine Einteilung nicht primär nach Hosting-Standort, sondern nach Kontrolle über die Verarbeitungsdefaults. Das Spektrum reicht von „du baust selbst, du bestimmst alles" bis zu „du klickst zu, was der Anbieter dir hinstellt".

Auf der einen Seite stehen die selbst gehosteten OSS-Plattformen — Forgejo, Gitea, Gogs, GitLab CE. Der Betreiber ist gleichzeitig Default-Setzer, KI-Features sind nicht aktivierbar oder erfordern bewusstes Hinzufügen externer Dienste. Maximaler Aufwand, maximale Kontrolle.

Eine Stufe darunter rangieren die gemeinnützigen SaaS-Anbieter — Codeberg, Framagit, Disroot, 0xacab. Niedriger Aufwand, klare AGB-Position gegen die Verwertung von Nutzer-Code, dafür beschränkte Funktionsfülle und Storage. Sourcehut nimmt einen Sonderplatz ein: kommerziell, aber mit explizit dokumentierter Anti-KI-Position und EU-Hosting in Amsterdam.

Auf der anderen Seite stehen die etablierten Plattformen — GitHub, GitLab.com, Bitbucket, Azure DevOps. Funktional reif, datenpolitisch nicht unter Kontrolle des Kunden. Außerhalb dieser Sortierung liegen zwei Sonderfälle, die unten einzeln eingeordnet werden: Launchpad mit seinem Distro-Fokus und AWS CodeCommit als Lehrstück über Plattform-Risiko.

Vergleichstabelle: Die wichtigsten Kandidaten

Einen klaren Sieger gibt die Tabelle nicht her. Sie zeigt aber zwei Cluster: einen Sweet-Spot bei Codeberg, Forgejo und GitLab CE, und einen Schlusslicht-Bereich rechts unten. Dazwischen bewegen sich die Sonderfälle, die für bestimmte Use-Cases trotzdem die richtige Wahl sind.

Codeberg: Der naheliegendste Einstieg ohne eigenen Server

Codeberg ist die einzige Plattform in dieser Übersicht, die als Verein organisiert ist — nach deutschem Recht, mit Sitz in Berlin, betrieben auf Servern in Deutschland. Mitgliedsbeiträge tragen den Betrieb, ergänzt durch Spenden. Kein Investorengeld, keine Monetarisierung über Nutzerdaten, keine KI-Features in Sicht. Die AGB schließen kommerzielle Nutzung nutzergenerierter Inhalte explizit aus.

Was Codeberg von der bloßen Hosting-Behauptung unterscheidet, ist eine zitierfähige Maßnahme: Seit 2023 werden bekannte KI-Crawler — GPTBot, ClaudeBot, CCBot, Google-Extended — serverseitig mit HTTP 403 abgewiesen. Das ist technisch nachprüfbar und im Streitfall belegbar.

Die Grenzen sind ehrlich kommuniziert: 2 GB Storage-Quota pro Repo, größere Projekte müssen anfragen. Für Enterprise-Bedarf — SCIM, eigene Domains, ISO-27001-taugliche Audit-Logs — ist Codeberg nicht ausgelegt. Bei mehr als rund 30 Entwicklern oder dreistelliger Repo-Zahl wird Self-Hosting ohnehin attraktiver.

Forgejo Self-Hosted: Das technische Optimum

Forgejo entstand 2022 als Hard-Fork von Gitea, getragen von der Codeberg-Community. Das Binary ist eine einzige Go-Datei, die Datenbank kann SQLite, MySQL, MariaDB oder PostgreSQL sein. Auf einem 4-GB-Server läuft es problemlos für 50 Entwickler.

Das eigentliche Argument für Forgejo ist Forgejo Actions: die hauseigene CI, die Workflows nahezu unverändert aus GitHub übernimmt. actions/checkout@v4, actions/setup-node@v4 und ein Großteil der Marketplace-Actions funktionieren entweder direkt oder über drop-in-Mirrors auf code.forgejo.org. Wer aus dem GitHub-Universum migriert, hat hier den niedrigsten Reibungsverlust.

Ein typisches Setup mit Docker Compose:

services:
  forgejo:
    image: codeberg.org/forgejo/forgejo:8
    restart: unless-stopped
    environment:
      - FORGEJO__database__DB_TYPE=postgres
      - FORGEJO__database__HOST=db:5432
      - FORGEJO__database__NAME=forgejo
      - FORGEJO__database__USER=forgejo
      - FORGEJO__database__PASSWD=${DB_PASSWORD}
      - FORGEJO__server__ROOT_URL=https://git.example.de
      - FORGEJO__service__DISABLE_REGISTRATION=true
    volumes:
      - ./data:/data
    ports:
      - "3000:3000"
      - "2222:22"
    depends_on: [db]

  db:
    image: postgres:16
    restart: unless-stopped
    environment:
      - POSTGRES_DB=forgejo
      - POSTGRES_USER=forgejo
      - POSTGRES_PASSWORD=${DB_PASSWORD}
    volumes:
      - ./pgdata:/var/lib/postgresql/data

  runner:
    image: code.forgejo.org/forgejo/runner:6
    restart: unless-stopped
    environment:
      - FORGEJO_INSTANCE_URL=https://git.example.de
      - FORGEJO_RUNNER_REGISTRATION_TOKEN=${RUNNER_TOKEN}
    volumes:
      - ./runner-data:/data
      - /var/run/docker.sock:/var/run/docker.sock

Drei Container, ein paar Umgebungsvariablen — und die Plattform läuft. Was anschließend zu tun ist, gehört in Teil 3.

Gogs: Der Großvater dieser Linie

Gogs ist die ursprüngliche Go-basierte Git-Hosting-Software, von der Gitea sich 2016 abgespaltet hat — und Forgejo später wiederum von Gitea. Wer heute auf Gogs schaut, sollte zwei Dinge wissen.

Erstens: Gogs wird weiterhin gepflegt, aber mit deutlich geringerer Veränderungsgeschwindigkeit als Gitea oder Forgejo. Maintainer Unknwon (Jiahua Chen) hat die Roadmap zuletzt im Frühjahr 2024 öffentlich aktualisiert; Sicherheitspatches kommen, neue Features eher zurückhaltend. Zweitens: Gogs hat keine native CI. Wer auf Gogs setzt, kombiniert es mit einer separaten Lösung — historisch gerne Drone CI (das ursprünglich auf Gogs aufbaute), heute auch Woodpecker CI als Drone-Fork mit klarer OSS-Ausrichtung, oder Jenkins.

Diese Trennung kann Vorteil sein — lose gekoppelte Architektur, freie CI-Wahl — oder Nachteil — mehr Komponenten, mehr Integrationsarbeit. Für den Datenschutz-Fokus dieser Serie ist Gogs eine ehrenwerte Option für Setups, die ohnehin entkoppelt arbeiten wollen oder eine sehr ressourcenarme Installation brauchen. Für Migrationen aus GitHub mit großem Action-Bestand ist Forgejo die pragmatischere Wahl.

Launchpad: Der Sonderfall aus dem Ubuntu-Universum

Launchpad ist Canonicals Plattform, ursprünglich für die Ubuntu-Distribution gebaut, gehostet in Großbritannien. Sie unterstützt Bazaar — das Canonical-eigene VCS — und Git, hat eine eigene Bug-Tracking-Logik mit Verbindung zur Debian-BTS, einen Translations-Workflow, eine Mailing-List-Engine und vor allem die Build-Farm: ein riesiges Cluster, das Pakete für alle Ubuntu-Architekturen baut.

Für allgemeine Software-Projekte ist Launchpad selten die richtige Wahl. Der Workflow ist tief auf Ubuntu/Debian-Paketierung zugeschnitten, das UI wirkt wie aus den frühen 2010ern, und die Build-Farm baut .deb-Pakete — keine beliebigen Container oder Test-Suiten. Für Projekte mit Distro-Bezug (Hardware-Treiber, Kernelmodule, System-Daemons) bleibt Launchpad dagegen unverändert sinnvoll, vor allem als offizielle Brücke zu PPAs (Personal Package Archives).

Datenschutzpolitisch sitzt Canonical post-Brexit zwar außerhalb der EU, aber mit eigener Angemessenheitsentscheidung der EU-Kommission. Keine bekannten KI-Features, kein Default-on-Trainings-Schalter, stabile ToS über die Jahre. In der Default-off-Wertung damit klar im oberen Drittel — wegen der speziellen Use-Case-Ausrichtung aber kein universeller Ersatz.

AWS CodeCommit: Das Lehrstück über Plattform-Risiko

AWS CodeCommit verdient hier einen eigenen Abschnitt, allerdings als Warnung. Im Juli 2024 hat AWS angekündigt, den Dienst für Neukunden zu schließen. Bestehende Kunden können CodeCommit weiter nutzen, aber neue AWS-Konten haben keinen Zugriff mehr, und die Service-Roadmap wurde eingefroren. Begründung: Fokus auf „core priorities". Im Klartext: AWS hat den Markt an GitHub und GitLab verloren und zieht sich zurück.

Für die Datenschutz-Diskussion ist CodeCommit damit irrelevant geworden — für die strategische Diskussion umso wertvoller. Es zeigt, was passiert, wenn man Code-Hosting bei einem Anbieter konzentriert, der den Dienst nicht als Kerngeschäft betrachtet: Nach dreizehn Jahren Betrieb und Millionen Repositories kann der Anbieter „nein, danke" sagen. Dasselbe Risiko besteht latent bei anderen Hyperscaler-Code-Diensten — Azure DevOps wird seit Jahren nur noch im Erhaltungsmodus weiterentwickelt, mit klarem Steuerungsdruck Richtung GitHub.

Wer CodeCommit heute noch nutzt, hat einen Migrationsdruck unabhängig von Datenschutzfragen. Das ist eine eigene Migration, die parallel zu der hier diskutierten laufen sollte.

GitLab CE Self-Hosted: Wenn das Unternehmen größer ist

Für Unternehmen ab hundert Entwicklern, mit Compliance-Anforderungen oder komplexen Berechtigungsmodellen, wird GitLab CE attraktiv. Funktional bietet die Community-Edition alles, was auf gitlab.com auch in der Free-Tier verfügbar ist — Container-Registry, Pages, Wiki, Issues, MR-Workflows. Zusätzliche Features, die in CE fehlen, liefert die Enterprise-Edition.

Genau diese Trennung ist für die Default-off-Argumentation entscheidend: GitLab Duo, das KI-Feature, ist nur in EE verfügbar und in CE nicht aktivierbar. Wer CE betreibt, hat damit eine harte Garantie gegen versehentliche KI-Anbindung — eine, die niemand durch Klick aufweichen kann.

Der Ressourcenbedarf ist nicht zu unterschätzen: 4 vCPU und 8 GB RAM sind das Minimum, 16 GB die Empfehlung. Backup ist nicht-trivial, weil Repository-, Datenbank-, LFS-, Artifact- und Registry-Storage konsistent gesichert werden müssen. Das offizielle gitlab-backup-Tool deckt das ab — gehört aber regelmäßig restore-getestet.

Sourcehut: Wenn Konsequenz wichtiger ist als Komfort

Sourcehut ist die ideologisch klarste Wahl. Drew DeVault hat KI-Crawler öffentlich als „Plage" bezeichnet und betreibt aggressives Blocking. Die Plattform liegt in Amsterdam, kostet ab zwei Euro pro Monat, und der Workflow läuft komplett ohne JavaScript — Patches werden per Mailing-Liste eingereicht (git send-email), Reviews ebenfalls.

Das ist gleichzeitig die größte Hürde. Wer mit Pull-Request-Workflows sozialisiert ist, muss umlernen. Für interne Unternehmensnutzung mit gewohnten Werkzeugen ist Sourcehut deshalb meist keine Option, für stark engagierte OSS-Projekte oder Solo-Entwickler dagegen ein konsequenter Schritt.

TDM-Reservation maschinenlesbar implementieren

Unabhängig von der gewählten Plattform sollten Unternehmen den TDM-Vorbehalt nach § 44b UrhG / Art. 4 DSM-Richtlinie maschinenlesbar setzen. Die juristisch sauberste Variante kombiniert vier Ebenen, die jeweils einen anderen Auslesepfad bedienen.

Die erste Ebene ist robots.txt im Root jedes Web-Hosts:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: anthropic-ai
Disallow: /

User-agent: PerplexityBot
Disallow: /

Die zweite Ebene ist ai.txt im Root, ein semi-formaler Standard von Spawning AI:

User-Agent: *
Disallow: /

Die dritte Ebene ist ein HTTP-Header auf allen Repository-URLs:

X-Robots-Tag: noai, noimageai

In Caddy als Reverse Proxy:

git.example.de {
    reverse_proxy localhost:3000
    header X-Robots-Tag "noai, noimageai"
}

Die vierte Ebene ist ein Lizenz- oder README-Vermerk als rechtlich primär ausgewerteter Text:

## Vorbehalt nach § 44b UrhG / Art. 4 DSM-RL

Die Rechteinhaber dieses Repositories behalten sich gemäß § 44b Abs. 3
UrhG und Art. 4 Abs. 3 der Richtlinie (EU) 2019/790 die Nutzung der
hier veröffentlichten Inhalte für Text- und Data-Mining ausdrücklich
vor. Eine Nutzung zum Training von KI-Modellen, einschließlich
Large Language Models, ist ohne ausdrückliche schriftliche
Genehmigung untersagt.

Die Kombination aller vier Ebenen ist der derzeit beste verfügbare Stand. Ob KI-Anbieter sich daran halten, ist eine andere Frage — aber im Streitfall, etwa bei einer Klage nach AI Act ab August 2026, ist die maschinenlesbare Konformität der entscheidende Beweis.

Welche Lösung für welche Größenordnung?

Die Auswahl folgt der Größenordnung, nicht der Ideologie. Bis ungefähr zehn Entwickler oder rein für OSS-Projekte ist Codeberg der naheliegende Einstieg: kein eigener Betrieb, gemeinnütziger Träger, klare Default-off-Position.

Für zehn bis hundert Entwickler im kommerziellen Umfeld lohnt Forgejo self-hosted. Niedriger Betriebsaufwand, gute Migrationspfade aus GitHub, hauseigene CI mit Actions-Kompatibilität — das ist heute der pragmatische Pfad. Ab hundert Entwicklern oder mit harten Compliance-Anforderungen wird GitLab CE attraktiv: höherer Betriebsaufwand, dafür funktional auf Enterprise-Niveau und sauber abgrenzbar gegen KI-Features.

Für Sonderfälle gilt anderes. Solo-Entwickler oder kleine OSS-Projekte mit ideologischer Klarheit landen bei Sourcehut. Wer Distro- oder Paketierungs-Bezug hat, ergänzt Launchpad — als Ergänzung, nicht als Ersatz. Wer eine entkoppelte Architektur bevorzugt, kombiniert Gogs mit Woodpecker CI als ressourcenschonende Variante.

Vom Vergleich zur Migration

Damit ist die Anbieter-Landschaft kartiert. Teil 3 dieser Serie wird operativ: Wie sieht die konkrete Migration aus, mit Schwerpunkt auf den schwierigsten Punkt — die CI-Pipeline. Mit Beispielen für die Übersetzung von GitHub Actions nach Forgejo Actions, einer Anleitung für die Einrichtung self-hosted Runner und einer abhakbaren Migrations-Checkliste.

Diese Serie:

• Teil 1: Default-on ab 24. April – GitHub trainiert Copilot mit Nutzer-Code
• Teil 2: Alternativen im Vergleich – Codeberg, Forgejo, Gogs, Launchpad und mehr (dieser Artikel)
• Teil 3: Migration mit CI-Fokus – vom Plan zur Ausführung