Zu den aktuellen Listenpreisen startet ein 3-köpfiges Team mit GitHub Team, Vercel Pro, Sentry Team, Linear Basic und Notion Plus bei rund 158 $ im Monat, noch ohne 1Password, nutzungsabhängige Gebühren und Add-ons. Ein sorgfältig zugeschnittener selbst gehosteter Stack kann diese Rechnung deutlich senken, doch zum fairen Vergleich gehören ein größerer VPS als die 4-GB-Laboruntergrenze und die Wartungszeit, die alle vergessen.
Dieser Leitfaden richtet sich an Entwickler oder kleine Teams, die bereits entschieden haben, dass „die SaaS-Rechnung nervt“ und dass „privater Code und Entwickler-Workflows auf fremder Infrastruktur ein ungutes Gefühl machen“, und nun wissen wollen, was konkret zu betreiben ist. Der Stack hat vier Schichten: Code, Build und Deployment, Betrieb und Dokumentation. Jede Schicht bekommt ein empfohlenes Werkzeug, eine Alternative, die Ressourcenkosten und den Fehlerfall. Der Rahmen ist die private und Team-Nutzung auf einem einzigen VPS. E-Mail-Hosting, DNS, kundenseitige Authentifizierung und Kubernetes bleiben außen vor, aus Gründen, die wir an passender Stelle nennen.
Die Kurzfassung
Wenn Sie nur die Stichpunkte lesen:
- Code: Forgejo als Standard. GitLab CE nur, wenn Sie git, CI/CD, Registry und Issues in einem Produkt wollen; GitLabs aktuelle Single-Node-Basis liegt bei 16 GB RAM, die 8 GB sind für speicherbeschränkte Umgebungen reserviert.
- Build und Deployment: Coolify on the current stable release (v4.3.0 at QC time), with the dashboard kept off the public internet. Dokku suits solo developers; pure Docker Compose suits teams that prefer visible moving parts.
- Ausführen: Vaultwarden für gemeinsame Zugangsdaten, Uptime Kuma für Monitoring, GlitchTip für Error-Tracking und Portainer oder Dockge für die Container-Verwaltung. GlitchTip ist ein deutlich kleineres Deployment als selbst gehostetes Sentry, dessen offizielles Minimum bei 16 GB RAM plus 16 GB Swap liegt.
- Dokumentieren: Docmost für die Dokumentation und OpenProject (oder Plane) für das Issue-Tracking. AFFiNE passt zu Teams, die ein Notion-Modell im Canvas-Stil bevorzugen.
- Dimensionierung: Betrachten Sie 4 GB als Laborgröße für ein paar leichte Dienste, 8 GB als reduzierten Piloten ohne OpenProject, Plane oder lokale Builds und 16 GB als praktischen Startpunkt für den vollständigen Forgejo-Stack aus diesem Leitfaden. GitLabs Basis von 8 vCPU und 16 GB gilt für GitLab selbst, ein GitLab-basierter Ein-Maschinen-Stack braucht daher zusätzliche Kapazität oder eigene Lasttests.
- Wo er verliert: Öffentliche Open-Source-Projekte mit externen Beitragenden. Der Netzwerkeffekt von GitHub ist real, und Selbsthosting kostet Sie Auffindbarkeit.
Voraussetzungen
Bevor Sie weiterlesen, setzt dieser Leitfaden voraus:
- Ein Linux-VPS mit installiertem Docker und Docker Compose. Planen Sie rund 16 GB RAM für den vollständigen Forgejo-Stack ein; 8 GB genügen für einen reduzierten Piloten ohne die schwereren Projektmanagement-Werkzeuge und lokale Builds.
- 30 bis 60 Minuten Aufmerksamkeit pro Schicht für das erste Deployment.
- Sicherheit im Lesen einer Compose-Datei und im Anpassen von Umgebungsvariablen.
- Die Bereitschaft, ein regelmäßiges Update-Fenster einzuhalten, Sicherheitsfixes zügig einzuspielen und Backups zu überprüfen, statt sie nur einzurichten.
Wenn einer dieser Punkte ein Ausschlusskriterium ist, ist das SaaS-Paket wirklich die richtige Antwort für Ihr Team. Das ist eine vertretbare Position, kein Scheitern.
Entwickeln Sie auf einem Linux-VPS mit Root-Zugriff, NVMe und AMD-EPYC-Power.
Linux-Pläne ansehenSchicht 1, Code: Forgejo, Gitea oder GitLab CE
Drei tragfähige Optionen, drei verschiedene Punkte auf der Kurve aus Ressourcen und Governance. Für Neueinsteiger ins Selbsthosting 2026 lautet die Empfehlung zuerst Forgejo.
Forgejo ist auf bescheidene Infrastruktur ausgelegt und bietet Pull Requests, Issue-Tracking, Projektboards, Wikis, Paket-Registries und Forgejo Actions. Seine Workflows nutzen ein Format im Stil von GitHub Actions, doch die Kompatibilität ist nicht absolut; testen Sie jede Drittanbieter-Action, von der Ihre Pipeline abhängt.
Wählen Sie Gitea nur, wenn Sie bereits von einer Gitea-exklusiven Funktion abhängen oder Ihr Tooling auf eine Gitea-Version festgelegt ist. An der Codebasis ist nichts auszusetzen. Der offizielle Vergleich von Forgejo besagt, dass der Fork auf die Übertragung der Domains und der Marke von Gitea an ein gewinnorientiertes Unternehmen im Oktober 2022 ohne Zustimmung der Community folgte; die Lizenzankündigung von Forgejo hält GPL v3+ für Versionen ab v9.0 fest.
Wählen Sie GitLab CE, wenn Sie ein einziges Produkt für git, CI/CD, Container-Registry und Issue-Tracking wollen und sich dessen Ressourcenuntergrenze leisten können. Die aktuellen Anforderungen von GitLab setzen 16 GB RAM und 8 vCPU als Single-Node-Basis; die 8 GB gelten speicherbeschränkten Umgebungen. Gitea ist leicht genug, um eine kleine private Instanz in etwa 1 bis 2 GB RAM zu betreiben, und Forgejo ist vergleichbar, doch die Produktionsdimensionierung hängt bei beiden weiterhin von Repositories, Runnern und gleichzeitigen Nutzern ab.
| Tool | Startressourcen | Trägerschaft | Lizenz | Integriertes CI/CD | Wann wählen |
|---|---|---|---|---|---|
| Forgejo | 1-2 vCPU / 1-2 GB RAM (Schätzung für leichte Nutzung) | Community-getrieben (Codeberg e.V.) | GPL v3+ (v9.0+) | Forgejo Actions; Kompatibilität testen | Standardwahl für Neueinsteiger ins Selbsthosting 2026 |
| Gitea | 1-2 vCPU / 1-2 GB RAM (Schätzung für leichte Nutzung) | Gewinnorientiert (Gitea Ltd, seit Okt. 2022) | MIT | Gitea Actions; Kompatibilität testen | Bestehende Gitea-Abhängigkeit oder auf eine bestimmte Version festgelegtes Tooling |
| GitLab CE | 8 vCPU / 16 GB RAM baseline; 8 GB constrained | GitLab Inc | MIT (Community Edition) | Nativ, voller Funktionsumfang | Sie wollen eine Plattform für git, CI/CD, Registry und Issues und haben den RAM |
Die CI-Frage verdient einen Hinweis. Gitea Actions ist auf weitgehende Kompatibilität mit GitHub Actions ausgelegt, während Forgejo Actions bewusst auf Vertrautheit statt auf volle Kompatibilität zielt. Viele Workflows brauchen nur kleine Anpassungen, doch Runner-Images, Berechtigungen, Kontexte, Labels und Drittanbieter-Actions können sich anders verhalten. Testen Sie vor der Migration jeden Workflow und jede Action, von der Ihre Pipeline abhängt.
Ein Vorbehalt gilt für alle drei Optionen. Dieser Leitfaden setzt private und Team-Nutzung voraus, mit der Admin-Oberfläche hinter einem VPN oder einer IP-Allowlist. Öffentliche Git-Dienste sehen sich Bot-Traffic, Missbrauch und Sichtbarkeitsabwägungen gegenüber, die ein kleines privates Deployment nicht kennt. Für öffentliches Open Source spiegeln Sie zur Sichtbarkeit auf GitHub und behalten Forgejo als Quelle der Wahrheit, falls Ihnen dieses Governance-Modell wichtig ist.
Dimensionieren Sie den Server nach der Last, nicht nach den Tarifnamen eines Anbieters. Ein eigenständiger Forgejo- oder Gitea-Dienst für leichte private Nutzung kann bei rund 1 bis 2 vCPU und 1 bis 2 GB RAM starten. Ein reduzierter Stack ohne OpenProject, Plane oder lokale Builds startet bei etwa 4 vCPU und 8 GB RAM. Für den hier beschriebenen vollständigen Forgejo-Stack beginnen Sie bei etwa 8 vCPU und 16 GB RAM und prüfen ihn dann unter echter CI- und Anwendungslast. GitLabs offizielle Basis von 8 vCPU und 16 GB gilt für GitLab selbst, halten Sie sie also nicht für ausreichend für GitLab plus den Rest dieses Stacks. Nutzen Sie SSD- oder NVMe-Speicher, budgetieren Sie Repositories, Container-Images, Logs, Datenbanken und Backups getrennt und halten Sie 20 bis 30% Kapazität für Updates und Lastspitzen frei.
Kernaussage des Abschnitts: Forgejo ist 2026 die Standardempfehlung für die Code-Schicht; Gitea bleibt solide, und GitLab CE ist nur dann die integrierte Wahl, wenn Sie sich dessen 16-GB-Basis leisten können oder bewusst in einer auf 8 GB beschränkten Konfiguration arbeiten.
Schicht 2, Build und Deployment: Coolify (mit Vorbehalten), Dokku oder reines Docker Compose
Ehrlich eingeordnet: Coolify ist die empfohlene PaaS-Option für diesen Stack, wenn Sie das aktuelle Produktions-Release fahren, das Admin-Dashboard aus dem öffentlichen Internet heraushalten und Sicherheitshinweise verfolgen. Zum QC-Zeitpunkt kennzeichnet GitHub Coolify v4.3.0 als aktuellste Version. Behandeln Sie Patchen und die Isolierung der Admin-Ebene als Betriebsanforderungen, nicht als optionale Härtung.
Profi-Tipp: Schränken Sie Dashboard und API von Coolify mit einer Firewall, einem VPN oder einem vertrauenswürdigen Zugriffs-Proxy ein. Ausgerollte Anwendungen dürfen weiterhin öffentlichen Traffic erhalten; das Ziel ist, die Exposition der administrativen Steuerungsebene zu verringern.
Die Alternative für Solo-Entwickler ist Dokku, ein kompaktes PaaS mit Deployments per git push im Heroku-Stil und Buildpack-Unterstützung. Seine Angriffsfläche ist kleiner als die von Coolify, sein Funktionsumfang entsprechend ebenso. Das macht es zur vertretbaren „langweiligen Wahl“ für ein bis zwei Entwickler, die kein Dashboard brauchen.
Die dritte Option, zu der erfahrene Betreiber greifen, ist gar kein PaaS, nur Docker Compose. Wenn Ihr Team ohnehin Compose-Dateien schreibt und Sie die beweglichen Teile sehen wollen, ist das eine völlig vernünftige Antwort. Ergänzen Sie Dockge oder Portainer als UI-Schicht für die Stack-Verwaltung, wenn Sie einen Neustart per Klick statt docker compose restart möchten. Der Kompromiss ist betrieblicher Natur: keine Preview-Umgebungen, keine eingebaute TLS-Automatisierung, keine Deployments ohne Ausfallzeit ohne Aufwand. Diese Funktionen erarbeiten Sie sich mit Skripten; bei Coolify sind sie fertig eingebaut, samt der Sicherheitshistorie, die daran hängt.
Cloudzys Leitfaden zu den besten CI/CD-Werkzeugen geht tiefer auf die Build-Pipeline ein, für Teams, die einen separaten Runner brauchen. Viele kleine Teams brauchen ihn nicht mehr, sobald Forgejo Actions oder GitLab CI/CD steht.
Kernaussage des Abschnitts: Coolify ist nur auf dem aktuellen stabilen Release und mit eingeschränkter Admin-Ebene das empfohlene PaaS; Dokku ist die konservative Solo-Wahl; reines Docker Compose bleibt eine vertretbare dritte Option.
Schicht 3, Betrieb: Vaultwarden, Uptime Kuma, GlitchTip und Container-Verwaltung
Hier sitzt die krasseste Ressourcenlücke dieses Stacks. Die offiziellen Anforderungen für selbst gehostetes Sentry nennen als Minimum 4 CPU-Kerne, 16 GB RAM, 16 GB Swap und 20 GB freien Speicherplatz, empfohlen werden 32 GB RAM. Die Installationsanleitung von GlitchTip empfiehlt 512 MB RAM, setzt PostgreSQL voraus und macht Valkey optional. Für ein kleines Team auf einem VPS ist GlitchTip die praktische Standardwahl.
| Tool | RAM (typisch) | Anzahl Container | API-Kompatibilität |
|---|---|---|---|
| Selbst gehostetes Sentry | 16 GB RAM plus 16 GB swap minimum; 32 GB recommended | Großes Deployment mit vielen Diensten | Nativ |
| GlitchTip | 512 MB recommended; 256 MB minimum for the all-in-one setup | 2 Kerndienste; Valkey optional | Traffic der Sentry-SDKs; Funktionsparität prüfen |
Die vier übrigen Werkzeuge dieser Schicht sind schnell erzählt.
Vaultwarden ist ein Bitwarden-kompatibler Passwortmanager, der die mobilen Bitwarden-Apps und Browser-Erweiterungen sowie Team-Freigaben unterstützt. Sein tatsächlicher Fußabdruck hängt von Nutzern, Anhängen und der Wahl der Datenbank ab. Cloudzys Vergleich selbst gehosteter Passwortmanager geht dem Kompromiss auf den Grund, wenn Sie stärker strukturierte Berechtigungen, Audit-Kontrollen oder ein anderes Sicherheitsmodell brauchen.
Uptime Kuma ist das kleine Monitoring- und Alerting-Werkzeug: Prüfungen für HTTP, TCP, Ping, Push und Zertifikatsablauf sowie optionale Statusseiten. Benachrichtigungen können über Chat, E-Mail oder Webhooks laufen. Der Ressourcenbedarf schwankt mit der Zahl der Monitore und der Aufbewahrung; erst beim zweiten Fehlschlag in Folge zu alarmieren, dämpft kurze Aussetzer wirkungsvoll.
GlitchTip ist der Error-Tracker. Die meisten Sentry-SDK-Integrationen können an eine GlitchTip-DSN melden, doch die Funktionsparität ist unvollständig; testen Sie Performance-Monitoring, Source Maps, Alerts und jede Integration, die Ihr Team als kritisch einstuft.
Wählen Sie Portainer oder Dockge als Container-Oberfläche. Portainer deckt breitere Anwendungsfälle der Container-Verwaltung ab; Dockge bleibt auf Docker Compose fokussiert. Für einen kleinen reinen Compose-Stack passt Dockge sauberer. Wechseln Sie erst zu Portainer, wenn Sie den größeren Umfang brauchen.
Eine nützliche Compose-Ergonomie für diese Schicht: Halten Sie jedes Werkzeug in einem eigenen Unterverzeichnis mit eigener compose.yml, teilen Sie ein Docker-Netzwerk nur dort, wo Traffic zwischen Werkzeugen nötig ist, und setzen Sie einen einzigen Reverse Proxy davor für die TLS-Terminierung.
# /opt/stack/glitchtip/compose.yml (excerpt)
services:
web:
image: "glitchtip/glitchtip:${GLITCHTIP_VERSION:?Set GLITCHTIP_VERSION in .env}"
environment:
DATABASE_URL: "${DATABASE_URL:?Set DATABASE_URL in .env}"
SECRET_KEY: "${GLITCHTIP_SECRET_KEY:?Set GLITCHTIP_SECRET_KEY in .env}"
GLITCHTIP_DOMAIN: "https://errors.example.com"
DEFAULT_FROM_EMAIL: "[email protected]"
ports:
- "127.0.0.1:8000:8000"
Profi-Tipp: Ein Backup ist erst bewiesen, wenn sich der Dienst wiederherstellen und seine Daten prüfen lassen. Stellen Sie einmal im Monat einen repräsentativen Dienst in einer isolierten Testumgebung wieder her, starten Sie ihn, melden Sie sich an, sehen Sie Datensätze und Anhänge durch und bestätigen Sie, dass sich die Anwendung normal verhält. Die wiederhergestellten Dateien aufzulisten beweist nur, dass das Archiv lesbar ist, nicht dass Datenbank, Volumes, Berechtigungen und Anwendungszustand erfolgreich zurückgeholt werden können.
Kernaussage des Abschnitts: GlitchTip erledigt die Kernaufgabe des Error-Trackings mit einem drastisch kleineren Deployment als selbst gehostetes Sentry, doch prüfen Sie die Sentry-Funktionen und -Integrationen, die Ihr Team tatsächlich nutzt.
Schicht 4, Dokumentation: Docmost, AFFiNE und Issue-Tracking mit OpenProject oder Plane
Notions Oberfläche ist völlig in Ordnung, bis ein wachsendes Wiki Navigation und Suche träge wirken lässt. Für ein kleines Team lautet die empfohlene Aufteilung: Docmost für Dokumentation und Wiki, OpenProject für das Issue-Tracking. Ersetzen Sie OpenProject durch Plane, wenn Ihr Team ausdrücklich ein visuelles Modell im Stil von Linear will und dessen unterstütztes Selbsthosting betreuen mag.
Docmost ist hier der nächstliegende selbst gehostete Notion-Ersatz, ohne vorzugeben, Notion zu sein. Sein Block-Editor, die Seitenhierarchie und die Team-Berechtigungen passen zu einem klassischen internen Wiki. Dimensionieren Sie diese Schicht nach gleichzeitigen Bearbeitern, Anhängen und danach, ob PostgreSQL und Redis denselben Host teilen. AFFiNE ist die Alternative für Teams, die ein Canvas- und Whiteboard-Modell verschachtelten Seiten vorziehen. Beide sind vernünftig; entscheiden Sie sich für eines.
OpenProject deckt das Issue-Tracking für Teams ab, die mit einem Workflow im Jira-Stil zurechtkommen: Epics, Arbeitspakete, Sprints und Zeiterfassung. Plane ist die Alternative im Linear-Stil, mit einer schnelleren, issue-zentrierten Oberfläche und einem anderen Betriebsprofil.
Ehrlich anerkannt: Die tastaturgetriebene Geschwindigkeit von Linear ist wirklich gut, und Plane bildet nicht jede Interaktion nach. Wenn der Workflow Ihres Teams auf dem Muskelgedächtnis für Linears Befehlsmenü beruht, ist die Migrationsreibung real. Das muss kein Ausschlusskriterium sein, aber es ist ein echter Preis.
Kernaussage des Abschnitts: Docmost übernimmt die interne Dokumentation, OpenProject oder Plane das Issue-Tracking; die Lücke bei der Tastatur-Bedienung gegenüber Linear ist die einzige Stelle, an der diese Schicht einen Kompromiss verlangt.
Was dieser Stack kostet und worauf er läuft
Der praktische Startpunkt für den vollständigen Forgejo-Stack auf einer Maschine liegt bei etwa 8 vCPU und 16 GB RAM. Betrachten Sie 2 vCPU und 4 GB RAM als Laborgröße für ein paar leichte Dienste und 4 vCPU und 8 GB RAM als reduzierten Piloten ohne OpenProject, Plane und lokale Builds. Der tatsächliche Bedarf hängt von gleichzeitigen Nutzern, CI-Aktivität, Datenbankwachstum, Anhängen, Image-Speicher, Logs und Aufbewahrung ab. Prüfen Sie den Stack daher unter echter Last und halten Sie 20 bis 30% Kapazität frei. Die Einstiegsstufe mit 16 GB kann für ein gering ausgelastetes Team aus 2 bis 3 Entwicklern die folgenden Dienste tragen, vorbehaltlich Lasttests:
- Forgejo
- Coolify
- Vaultwarden
- Uptime Kuma
- GlitchTip
- Docmost
- OpenProject
- Dockge
Ein Server mit 4 GB taugt nur für ein paar leichte Dienste. Einen Server mit 8 GB behandeln Sie besser als reduzierten Piloten ohne OpenProject, Plane oder lokale Builds. Starten Sie den vollständigen Forgejo-Stack bei 16 GB und legen Sie Kapazität nach, sobald GitLab, gleichzeitige Builds, Plane, lange Aufbewahrungsfristen oder schwerere Datenbanklasten dazukommen. Das SaaS-Paket desselben Teams umfasst:
- GitHub Team
- Vercel Pro
- Sentry
- Linear
- Notion
- 1Password
Auf Basis der veröffentlichten Grundpreise der jeweiligen Preisseiten (einschließlich der Jahresabrechnungspreise, wo zutreffend). Die fünf bepreisten Produkte summieren sich auf rund 158 $ im Monat für drei Personen: GitHub Team für 4 $ pro Nutzer in den ersten 12 Monaten, drei Entwicklerplätze bei Vercel Pro zu je 20 $, Sentry Team ab 26 $, Linear Basic zu 10 $ pro Nutzer, und Notion Plus zu 10 $ pro Nutzer. Nutzungsgebühren, Steuern, Add-ons und 1Password kommen obendrauf. Die Infrastruktur kann weiterhin spürbar günstiger sein, doch ohne die Zeit des Betreibers ist der Vergleich sinnlos.
Wann Sie aufstocken sollten: GitLabs Single-Node-Basis liegt bei 8 vCPU und 16 GB RAM. Mehrere gleichzeitige Builds können auch ohne GitLab zusätzliche Kapazität verlangen. Selbst gehostetes Sentry startet ebenfalls bei 16 GB RAM plus 16 GB Swap und empfiehlt 32 GB, weshalb dieser Leitfaden für den Ein-Maschinen-Stack GlitchTip empfiehlt.
Der unbepreiste Posten ist die Betriebszeit. Als Planungswert veranschlagen Sie 1 bis 2 Stunden im Monat für Updates und Backup-Prüfung, dazu wöchentlich einen kurzen Blick in die Sicherheitshinweise der Projekte, die Sie betreiben. Die tatsächliche Zahl hängt vom Änderungsvolumen, der Incident-Reaktion und Ihrem Automatisierungsgrad ab. Sie ist nicht null, und sie gehört ins Kostenmodell.
Die Deployment-Methode ändert den Komfort, nicht die Betriebsanforderungen. Ob Sie eine offizielle Compose-Datei oder eine Marketplace-Vorlage nutzen: pinnen Sie Image-Versionen, setzen Sie CPU- und Speichergrenzen, halten Sie Dienstdaten in benannten Volumes und testen Sie Backups wie Restores. Den kompletten Stack auf einem Host zu bündeln, schafft zudem eine gemeinsame Fehlerdomäne, isolieren Sie also kritische Dienste, wenn Ausfall oder offengelegte Zugangsdaten schwer wiegen würden.
Wenn Sie diesen Stack ausrollen wollen, vergleichen Sie unsere Cloud VPS Angebote nach CPU, RAM, SSD- oder NVMe-Speicher, Transfervolumen und Region und wenden Sie dann das Dimensionierungsschema von oben an. Für die schnellere Einrichtung stöbern Sie in unserem Ein-Klick-App-Katalog, pinnen Sie aber dennoch Versionen, setzen Sie Ressourcengrenzen und prüfen Sie Backups vor dem Produktivbetrieb.
Kernaussage des Abschnitts: Nehmen Sie 4 GB für ein kleines Labor, 8 GB für einen reduzierten Piloten und rund 8 vCPU mit 16 GB RAM als praktischen Startpunkt für den vollständigen Forgejo-Stack. Legen Sie Kapazität nach für GitLab, gleichzeitige Builds, schwerere Projektmanagement-Werkzeuge und wachsende Datenbanken.
Wo das Selbsthosten dieses Stacks wirklich scheitert
Vier Fehlermodi, klar benannt, denn der Rest dieses Leitfadens war ein Plädoyer für den Ansatz.
Fehlermodus 1: der Netzwerkeffekt von GitHub bei öffentlichen Open-Source-Projekten. Selbst gehostetes git ist für privaten Code richtig. Für Projekte, deren ganzer Wert davon abhängt, dass externe Beitragende Sie finden, ist es falsch. GitHub ist die erste Anlaufstelle für Entwickler. Pull Requests, Forks, Sterne, das implizite Vertrauenssignal, auf github.com zu sein, die Integrationen mit Drittanbieter-Werkzeugen, all das. Ist Ihr Projekt öffentliches Open Source, ist das ehrliche Muster: zur Sichtbarkeit auf GitHub spiegeln, die Quelle der Wahrheit auf Forgejo behalten. Erwarten Sie nicht, dass eine selbst gehostete Instanz GitHubs Auffindbarkeit für öffentliche Arbeit ersetzt. Sie wird es nicht.
Fehlermodus 2: Bot- und Scraper-Traffic auf öffentlichen Git-Instanzen. Öffentlich erreichbare Forgejo- und Gitea-Dienste brauchen Missbrauchskontrollen, Rate Limits, Monitoring und genug Kapazität für unvorhersehbaren Traffic. Dieser Leitfaden setzt private und Team-Nutzung voraus, mit der Admin-Oberfläche hinter einem VPN oder einer IP-Allowlist. Eine wirklich öffentliche Forge folgt einem anderen Bedrohungs- und Kapazitätsmodell.
Fehlermodus 3: die Wartungslast. „Sie sind die IT-Abteilung“ ist das Klischee, und es stimmt weitgehend. Updates zerschießen Dinge. Compose-Dateien driften. Zertifikate laufen ab. Backups scheitern still und auf die unwürdigsten Weisen. Coolifys Sicherheitshinweise aus 2026 erinnern nützlich daran, dass die Patch-Kadenz zählt. Wenn Sie sich vorab nicht auf ein Wartungsfenster festlegen können, ist das SaaS-Paket ehrlich gesagt die richtige Antwort.
Fehlermodus 4: der Verlust von Integrationen. Drittanbieter-Actions auf GitHub, Vercel-Preview-Deployments an GitHub-Pull-Requests gekoppelt, Sentrys gehostete Alerting-Integrationen mit PagerDuty und Linear, Notions breiter Integrationskatalog. Für das meiste gibt es selbst gehostete Gegenstücke (Forgejo Actions, Coolify-Deployments per Webhook, GlitchTip-Benachrichtigungen, n8n als Klebstoff zwischen Workflows), doch die Ersatzlösungen sind nicht immer eins zu eins. Bauen Sie einen Prototyp des wichtigsten Workflows, bevor Sie das Team auf die Migration festlegen. Die Integration, die Sie für selbstverständlich halten, wird Sie am ehesten überraschen.
Kernaussage des Abschnitts: Dieser Stack funktioniert für privaten Code, kleine Teams und willige Betreiber; er funktioniert nicht für die Sichtbarkeit öffentlicher Open-Source-Projekte, für Teams, die nichts anfassen wollen, oder für die Erwartung von null Wartung.
Der Stack des Betreibers
Vier Schichten, vier Empfehlungen, ehrlich benannt. Code: Forgejo. Build und Deployment: Coolify mit eingeschränkter Admin-Ebene, oder Dokku, oder Compose. Betrieb: Vaultwarden, Uptime Kuma, GlitchTip, Portainer oder Dockge. Dokumentation: Docmost und OpenProject (oder Plane). Starten Sie einen reduzierten Piloten bei 8 GB und den vollständigen Forgejo-Stack bei 16 GB. Legen Sie Kapazität nach für GitLab, gleichzeitige Builds, schwerere Datenbanken oder anhaltende Anwendungslast.
Wenn Sie migrieren, beginnen Sie mit Uptime Kuma und einem unkritischen internen Dienst. Damit lernen Sie die Betriebskadenz mit weniger Risiko (Updates, Monitoring, Backup-Prüfung und Zertifikatserneuerung), bevor Sie einen Team-Workflow oder einen Passwortspeicher umziehen. Machen Sie Vaultwarden nicht zum ersten Testdeployment: Ziehen Sie es erst um, wenn verschlüsselte Backups außerhalb des Hosts, ein erfolgreicher Restore-Test, eingeschränkte Administration und MFA stehen. Ist diese Kadenz verlässlich, folgen Forgejo, dann Coolify, dann der Rest.
Teams, die sich gezielt für GitLab CE entscheiden, sollten klären, ob dessen natives CI/CD einen separaten Runner ersetzt oder ob ihre Last weiterhin dedizierte Build-Kapazität braucht.
Häufig gestellte Fragen
Was ist 2026 die beste selbst gehostete Alternative zu Gitea?
Forgejo ist 2026 die empfohlene Wahl für Neueinsteiger ins Selbsthosting. Die Übertragung von Marke und Domain von Gitea an ein gewinnorientiertes Unternehmen im Oktober 2022 ohne vorherige Zustimmung der Community löste Ende 2022 den Forgejo-Fork aus. Ab v9.0 stehen Forgejo-Releases unter GPL v3+; frühere Patch-Releases v8.0 und v7.0 blieben unter MIT. Im Alltag ist die Funktionsparität nah beieinander.
Kann man Coolify 2026 sicher in Produktion betreiben?
Ja, aber nur mit aktiver Wartung und gestaffelter Verteidigung. Fahren Sie das neueste geprüfte stabile Release, verfolgen Sie neue Hinweise, schränken Sie Team-Berechtigungen ein und halten Sie Dashboard und API hinter einer Firewall, einem VPN oder einer vertrauenswürdigen Zugriffsschicht. Behandeln Sie beta.451, beta.474 oder irgendeinen anderen historischen Patchstand nicht als dauerhaft sichere Schwelle.
Wie viel RAM braucht ein vollständiger selbst gehosteter Entwickler-Stack wirklich?
Für ein Team aus 2 bis 3 Entwicklern gelten 4 GB als Laborgröße für ein paar leichte Dienste und 8 GB als reduzierter Pilot ohne OpenProject, Plane oder lokale Builds. Rund 8 vCPU und 16 GB RAM sind der praktische Startpunkt für den vollständigen Forgejo-Stack. GitLabs Basis von 8 vCPU und 16 GB gilt für GitLab selbst, während selbst gehostetes Sentry 16 GB RAM plus 16 GB Swap verlangt und 32 GB empfiehlt. Prüfen Sie die endgültige Konfiguration unter echten Lastbedingungen.
Warum GlitchTip statt selbst gehostetem Sentry?
Die Lücke bei Ressourcen und Betrieb. Selbst gehostetes Sentry verlangt mindestens 16 GB RAM plus 16 GB Swap und ist ein großes Deployment mit vielen Diensten. GlitchTip empfiehlt 512 MB für seinen All-in-one-Dienst, setzt PostgreSQL voraus und macht Valkey optional. Es nimmt den Traffic der Sentry-SDKs an, doch die Funktionsparität ist unvollständig, testen Sie also die Funktionen und Integrationen, auf die Sie angewiesen sind.
Was kostet dieser Stack im Vergleich zu den SaaS-Pendants wirklich?
Betrachten Sie 4 GB als Laborgröße für ein paar leichte Dienste und 8 GB als reduzierten Piloten ohne OpenProject, Plane oder lokale Builds. Rund 8 vCPU und 16 GB RAM sind der praktische Startpunkt für den vollständigen Forgejo-Stack. Zu den veröffentlichten Grundpreisen summieren sich GitHub Team, Vercel Pro, Sentry Team, Linear Basic und Notion Plus auf etwa 158 $ im Monat für drei Personen, vor 1Password, nutzungsabhängigen Gebühren, Steuern und Add-ons. Selbsthosting kann spürbar günstiger sein, doch die Zeit des Betreibers und die Backup-Infrastruktur sind echte Kosten.
