Sie können Gitea auf einem VoyraCloud VPS selbst hosten, indem Sie das vorinstallierte Anwendungsimage auswählen, den ersten Administrator über SSH erstellen und dann die Weboberfläche, HTTPS Git oder SSH Git für Ihre Repositories verwenden. Das Image entfernt den manuellen Installationsschritt, während die Kontorichtlinie, Domains, HTTPS, Repository-Zugriff, Updates, Backups und Vorfallreaktionen unter Ihrer Kontrolle bleiben.
TL;DR
- Das VoyraCloud Gitea-Anwendungsimage bietet eine vorinstallierte Gitea Community Edition-Instanz auf Cloud VPS und Residential IP VPS.
- Die Installationsseite ist vor der Lieferung gesperrt. Erstellen Sie den ersten Administrator über den SSH-Befehl, der in Ihren Ressourcendetails angezeigt wird, nicht über einen öffentlich zugänglichen Installationsassistenten.
- Der Port
3000ist an die Loopback-Schnittstelle des VPS gebunden. Verwenden Sie den SSH-Tunnel-Befehl in den Ressourcendetails für den ersten Weblogin; er ist nicht als öffentliches HTTP exponiert. - Fügen Sie eine Domain, einen Reverse-Proxy und browser-vertrauenswürdiges HTTPS hinzu, bevor Sie die Weboberfläche veröffentlichen oder HTTPS Git verwenden. Gitea SSH Git verwendet den separaten öffentlichen Port
2222, nachdem Sie einen öffentlichen Schlüssel zu Ihrem Konto hinzugefügt haben. - Die Registrierung neuer Benutzer ist standardmäßig deaktiviert. Der Administrator entscheidet, ob Benutzer manuell erstellt oder die Registrierungsrichtlinie geändert werden soll.
- Repositories, Konten, Probleme, Pull-Requests, Pakete, Anhänge, Konfiguration und Geheimnisse bleiben nach einem normalen VPS-Neustart bestehen, aber die Neustartbeständigkeit ist kein Off-Server-Backup.
- VoyraCloud führt nach der Lieferung keine automatischen Upgrades, Backups, Überwachungen oder Administrationsmaßnahmen für die Gitea-Instanz durch.
Was ist Gitea?
Gitea ist ein Open-Source-Softwareentwicklungsdienst zum Hosten von Git-Repositories und zur Zusammenarbeit an Quellcode. Es bietet eine Weboberfläche für standardisierte Git-Workflows zusammen mit Benutzerkonten, Organisationen, Repository-Berechtigungen, Pull-Requests, Problemen, Projekten, Wikis, Releases, Paketen, Webhooks und API-Zugriff.
Die offizielle Gitea-Dokumentation beschreibt die Installation und Verwaltung für Teams, die ihren eigenen Dienst betreiben möchten. Selbsthosting ist nützlich, wenn Sie den Repository-Dienst, den Speicherort, die Kontorichtlinie, den Netzwerkzugang, den Update-Zeitpunkt und den Backup-Prozess unter Ihrer eigenen Verwaltung haben möchten.
Ein Gitea VPS ist eine praktische Lösung für:
- Ein Entwickler, der private Repositories auf einem persönlichen Server möchte.
- Ein kleines Team, das Git-Hosting, Code-Überprüfung, Probleme und Organisationsberechtigungen benötigt.
- Eine Agentur, die separate Repositories für Kundenprojekte führt.
- Ein Infrastrukturteam, das Repositories über SSH-Schlüssel, Zugriffstoken, Webhooks oder APIs mit Bereitstellungssystemen verbindet.
- Ein Labor oder internes Umfeld, das eine leichte Alternative zu einer größeren Softwareentwicklungsplattform benötigt.
Selbsthosting macht die Wartung von Repository-Operationen nicht wartungsfrei. Jemand ist immer für die Sicherheit des Betriebssystems, Gitea-Updates, Authentifizierungsrichtlinien, HTTPS, Backups, Speicherwachstum, Missbrauchsprävention und Wiederherstellungstests verantwortlich.
Wie starten Sie mit dem VoyraCloud Gitea-Image?
Der schnellste Bereitstellungspfad besteht darin, einen unterstützten VoyraCloud VPS mit dem Gitea-Image zu erstellen und den privaten Administrator-Setup-Befehl aus den Ressourcendetails auszuführen. Sie müssen Docker, Gitea oder die anfängliche Datenbank nicht manuell installieren.
- Öffnen Sie die VoyraCloud-Seite für Gitea über den obigen Link und fahren Sie mit dem Kaufprozess für den VPS fort.
- Wählen Sie eine geeignete Cloud VPS- oder Residential IP VPS-Konfiguration aus. Cloud VPS ist die allgemeine Option für Git-Hosting; Residential IP VPS bleibt verfügbar, wenn Ihre breitere Arbeitslast speziell die Netzwerkmerkmale dieses Produkts benötigt.
- Wählen Sie eine beliebige Region aus, die derzeit von dem ausgewählten VPS-Produkt angeboten wird, und bestätigen Sie, dass Gitea im Abschnitt Images ausgewählt ist.
- Erstellen Sie den VPS und warten Sie, bis die Ressource und die Anwendung bereit sind.
- Öffnen Sie die Ressourcendetails und suchen Sie den Abschnitt Anwendung.
- Kopieren Sie den Admin-Setup-Befehl. Er folgt diesem Muster:
ssh -t -p <ssh-port> <ssh-user>@<server-ip> 'sudo /usr/local/sbin/voyra-gitea-create-admin'7. Führen Sie den Befehl von Ihrem Terminal aus und geben Sie den Benutzernamen und die E-Mail des Administrators ein. Giteas offizielle CLI generiert ein 24-stelliges einmaliges zufälliges Passwort und zeigt es nur in der aktuellen SSH-Sitzung an.
8. Kopieren Sie den SSH-Tunnel-Befehl aus dem Abschnitt Anwendung und halten Sie diese Terminal-Sitzung geöffnet. Er folgt diesem Muster:
ssh -N -L 3000:127.0.0.1:3000 -p <ssh-port> <ssh-user>@<server-ip>9. Öffnen Sie die lokale Zugriffs-URL in Ihrem Browser:
http://127.0.0.1:300010. Melden Sie sich mit dem Administratorkonto und dem einmaligen Passwort an und setzen Sie ein neues Passwort, wenn Gitea die Änderung verlangt.
11. Erstellen Sie ein privates Test-Repository, fügen Sie einen SSH-öffentlichen Schlüssel hinzu und überprüfen Sie einen SSH-Klon und Push.
12. Verbinden Sie Ihre Domain, konfigurieren Sie vertrauenswürdiges HTTPS, aktualisieren Sie die öffentlichen URL-Einstellungen von Gitea und bestätigen Sie, dass die generierten HTTPS-Klon-Links die beabsichtigte Adresse verwenden.
13. Starten Sie den VPS einmal neu und überprüfen Sie, ob Gitea automatisch mit dem Administrator, dem Test-Repository, der Commit-Historie, den Schlüsseln und den Einstellungen intakt zurückkehrt.
14. Erstellen Sie ein Off-Server-Backup und führen Sie einen Test-Wiederherstellung durch, bevor Sie sich auf die Instanz für wichtigen Quellcode verlassen.
Der Setup-Befehl ist absichtlich von der Webseite getrennt. Der öffentliche Installationsassistent ist bereits gesperrt, sodass ein Internetbesucher keine neue Instanz beanspruchen kann, indem er den ersten Administrator erstellt, bevor der Eigentümer dies tut. Der Befehl stoppt auch, wenn bereits ein Administrator existiert.
Verwenden Sie den SSH-Benutzernamen und den Port, die für Ihre VPS-Ressource angezeigt werden. Gehen Sie nicht davon aus, dass jeder Server root oder Port 22 verwendet. Die für die Verwaltung verwendete VPS-SSH-Verbindung ist auch anders als Giteas SSH-Git-Endpunkt auf Port 2222.
Was beinhaltet das Anwendungsimage?
Das Gitea-Anwendungsimage umfasst einen persistenten Single-Server-Startpunkt, keinen verwalteten Quellcode-Hosting-Dienst. Die Liefergrenze bestimmt, was Sie vor der regulären Nutzung durch das Team konfigurieren müssen.
| Geliefert durch das Anwendungsimage | Benutzerverwaltet oder nicht enthalten |
|---|---|
| Gitea Community Edition stabile Version, die für das Image genehmigt ist | Automatische Gitea-Updates |
| Ubuntu-basiertes VPS-Umfeld | Verwaltete Betriebssystemadministration |
| Gitea, das im offiziellen Container mit einer lokalen SQLite-Datenbank läuft | Externer PostgreSQL- oder MySQL-Dienst |
| Gesperrte Installationsseite | Öffentlicher Webinstallationsassistent |
| Privater SSH-Befehl zum Erstellen des ersten Administrators | Vorkonfigurierter Administrator oder festes Passwort |
| Registrierung standardmäßig deaktiviert | Automatische Bereitstellung von Teammitgliedern |
Web-Backend auf Loopback-Port 3000 | Öffentliche HTTP-Exposition, Domainregistrierung, Reverse-Proxy und automatisches HTTPS |
SSH Git auf Port 2222 | Vorkonfigurierte Benutzer-SSH-Schlüssel |
| Persistente Repositories, Datenbank, Konfiguration und Anwendungsdaten | Automatische Off-Server-Backups |
| Service-Wiederherstellung nach einem normalen VPS-Neustart | Hohe Verfügbarkeit oder automatisches Failover |
| Standard Gitea-Kollaborationsfunktionen | Verwaltete Runner, CI-Kapazität, SMTP, OAuth, LDAP oder externen Speicher |
Das Image enthält keine Beispiel-Repositories, Organisationen, Benutzer, Runner, Pakete, Drittanbieter-Anmeldeinformationen, E-Mail-Zustellung, eine Domain oder ein browser-vertrauenswürdiges Zertifikat. Es gibt auch keine Anwendungsg Geheimnisse in den Ressourcendetails preis.
Wie funktioniert die sichere Einrichtung des ersten Administrators?
Der erste Administrator wird über eine authentifizierte VPS-SSH-Sitzung erstellt, während die öffentliche Installationsseite von Gitea gesperrt bleibt. Dies verhindert das häufige Rennen, bei dem ein nicht initialisierter Webinstallateur aus dem Internet erreichbar ist und ein unbeabsichtigter Besucher die Einrichtung zuerst abschließt.
Das Anwendungsimage bereitet die Datenbank und die Konfiguration vor der Lieferung vor. Es aktiviert die Installationssperre von Gitea und deaktiviert die öffentliche Benutzerregistrierung. Der Admin-Setup-Befehl führt dann den offiziellen administrativen Befehl von Gitea innerhalb der Anwendungsumgebung aus.
Der Einrichtungsprozess sollte folgende Eigenschaften haben:
- Er fragt interaktiv nach dem Benutzernamen und der E-Mail.
- Er weist Giteas offizielle CLI an, ein 24-stelliges zufälliges Passwort zu generieren, anstatt Ihr gewähltes Passwort als Befehlszeilenargument zu übergeben.
- Er zeigt das einmalige Passwort nur im aktuellen SSH-Terminal an und schreibt es nicht in die Shell-Historie, eine Datei oder ein Protokoll.
- Er verlangt eine Passwortänderung beim ersten Weblogin.
- Er verweigert die Erstellung eines weiteren Administrators, nachdem der erste Administrator existiert.
- Er generiert kein persönliches Zugriffstoken oder SSH-Schlüssel für Sie.
- Er druckt keine internen Geheimnisse von Gitea aus.
Überprüfen Sie nach der Anmeldung Site Administration und die Benutzerregistrierungsrichtlinie. Die Registrierung ist standardmäßig deaktiviert, damit unbekannte Internetbenutzer keine Konten erstellen können. Sie können genehmigte Benutzer über die Administrationsoberfläche erstellen oder die Richtlinie ändern, wenn eine offene Registrierung eine absichtliche Anforderung ist und Sie einen Missbrauchskontrollplan haben.
Versenden Sie das einmalige oder endgültige Administratorkennwort nicht über Chat, ein Ticket oder ein gemeinsames Shell-Protokoll. Schließen Sie die ursprüngliche SSH-Sitzung nach der Passwortänderung. Fügen Sie einen zweiten Administrator nur hinzu, wenn es die betriebliche Verantwortung erfordert, und verwenden Sie ein separates normales Konto für routinemäßige Git-Arbeiten, wenn dies praktikabel ist.
Wie unterscheiden sich HTTPS Git und SSH Git?
HTTPS Git verwendet den Gitea-Webendpunkt hinter Ihrer vertrauenswürdigen HTTPS-Domain, während SSH Git einen dedizierten Gitea-SSH-Dienst und einen kontobezogenen öffentlichen Schlüssel verwendet. Beide unterstützen normale Klon-, Abruf-, Pull- und Push-Operationen, aber ihre Authentifizierungs- und Transportkonfiguration unterscheidet sich.
| Methode | Erstes Adressmuster | Authentifizierung | Beste Verwendung nach der Einrichtung |
|---|---|---|---|
| Erste Weboberfläche | http://127.0.0.1:3000 über SSH-Tunnel | Gitea-Benutzername und Passwort | Erster Login, Passwortänderung und private Einrichtung |
| Reguläre Weboberfläche | https://git.example.com | Gitea-Benutzername und Passwort | Repository-Browsing und Verwaltung nach der Domain-Einrichtung |
| HTTPS Git | https://git.example.com/<owner>/<repo>.git | Bevorzugen Sie ein persönliches Zugriffstoken für Git-Clients | Webbasierter Git-Transport nach der Domain- und vertrauenswürdigen HTTPS-Einrichtung |
| SSH Git | ssh://git@<server-ip>:2222/<owner>/<repo>.git | SSH-öffentlicher Schlüssel, der dem Gitea-Konto hinzugefügt wurde | Bequem für Entwickler-Git-Clients und Automatisierung mit verwalteten Schlüsseln |
| VPS-System-SSH | Ressourcenspezifischer Host und Port | VPS-SSH-Schlüssel oder aktuelle Serveranmeldeinformationen | Serveradministration und Erstadministrator-Setup, nicht Repository-Zugriff |
Für SSH Git:
- Erstellen oder wählen Sie einen SSH-Schlüssel auf Ihrem Arbeitsplatz aus.
- Melden Sie sich bei Gitea an und fügen Sie den öffentlichen Schlüssel unter den Kontoeinstellungen hinzu.
- Kopieren Sie die SSH-Klonadresse von der Repository-Seite.
- Überprüfen Sie den Host-Fingerabdruck bei der ersten Verbindung, anstatt einen unerwarteten Schlüssel ohne Überprüfung zu akzeptieren.
- Bewahren Sie den privaten Schlüssel auf dem Client auf und schützen Sie ihn mit geeigneten Datei-Berechtigungen und, wenn geeignet, mit einer Passphrase.
Gitea SSH Git sollte nicht nach dem Gitea-Webpasswort fragen. Port 2222 gehört zum Repository-Dienst; er bietet keine Server-Shell.
Für HTTPS Git erstellen Sie ein persönliches Zugriffstoken mit nur den Berechtigungen, die von diesem Client oder dieser Integration benötigt werden. Vermeiden Sie es, ein Token direkt in einen Befehl einzufügen, der in der Shell-Historie verbleibt. Verwenden Sie Ihren Git-Anmeldeinformationshelfer oder einen geheimen Speicher, der für Ihr Betriebssystem geeignet ist.
Warum sollten Sie eine Domain und HTTPS hinzufügen?
Eine Domain und browser-vertrauenswürdiges HTTPS schützen Webanmeldeinformationen und HTTPS Git-Verkehr und geben der Instanz eine stabile öffentliche Identität. Das Image hält den Port 3000 an der Loopback-Schnittstelle des VPS, sodass der Webdienst nicht öffentlich erreichbar ist, bis Sie absichtlich einen Reverse-Proxy konfigurieren.
Der offizielle Gitea-Reverse-Proxy-Leitfaden erklärt, wie Gitea hinter gängigen Proxys funktioniert. Eine Produktionsumgebung umfasst normalerweise:
- Ein DNS-Eintrag wie
git.example.com, der auf den VPS verweist. - Ein Reverse-Proxy, der auf den Ports
80und443lauscht. - Ein browser-vertrauenswürdiges TLS-Zertifikat für die Domain.
- Eine HTTP-zu-HTTPS-Weiterleitung.
- Weitergeleitete Host-, Client-Adresse- und Protokoll-Header, die mit der Proxy-Konfiguration übereinstimmen.
- Giteas öffentliche
ROOT_URLund Domain-Einstellungen, die auf die endgültige HTTPS-URL aktualisiert wurden. SSH_DOMAINund der angezeigte SSH-Port wurden aktualisiert, damit die Anweisungen zum Klonen von Repositories genau bleiben.
Überprüfen Sie nach der Adressänderung Folgendes:
- Die Anmeldeseite lädt ohne Zertifikatwarnung.
- Links, die von Gitea generiert werden, verwenden die HTTPS-Domain anstelle der alten IP-Adresse.
- HTTP Git-Klon und Push funktionieren über HTTPS.
- SSH-Klon-Links zeigen die richtige Domain und den richtigen Port an.
- Webhooks und OAuth-Callback-URLs, falls später konfiguriert, verwenden die beabsichtigte öffentliche Adresse.
- Große Pushes schlagen nicht aufgrund von Reverse-Proxy-Körper- oder Zeitüberschreitungsgrenzen fehl.
Das Anwendungsimage registriert die Domain nicht oder stellt das Zertifikat für Sie aus. Diese Schritte werden vom Benutzer verwaltet, da der endgültige Hostname und das DNS-Konto dem Seiteninhaber gehören.
Wie sollten Sie Benutzer und Repository-Zugriff organisieren?
Verwenden Sie individuelle Konten, Organisationsteams, Repository-Berechtigungen, SSH-Schlüssel und bereichsspezifische Tokens, anstatt eine Administratoridentität zu teilen. Gitea kann private und öffentliche Repositories hosten, aber der Administrator muss entscheiden, wer jedes Ressource entdecken, lesen, schreiben, überprüfen und verwalten kann.
Eine praktische Basislinie für kleine Teams ist:
- Halten Sie die öffentliche Registrierung deaktiviert, es sei denn, es gibt einen absichtlichen Grund, sie zu öffnen.
- Geben Sie jeder Person ein individuelles Konto.
- Reservieren Sie den Administratorzugang für Server- und Dienstbesitzer.
- Erstellen Sie Organisationen für verwandte Repositories und Teams für Berechtigungsgruppen.
- Gewähren Sie die geringste erforderliche Repository-Berechtigung für jede Rolle.
- Verwenden Sie Branchenschutz- und Überprüfungsregeln für wichtige Branches.
- Verwenden Sie Bereitstellungsschlüssel oder bereichsspezifische persönliche Zugriffstokens für die Automatisierung anstelle eines Administratorpassworts.
- Entfernen Sie Konten, Schlüssel und Tokens umgehend, wenn der Zugriff nicht mehr erforderlich ist.
- Aktivieren Sie die Zwei-Faktor-Authentifizierung für privilegierte Benutzer, wenn sie zu Ihrem Zugriffsmodell passt.
- Überprüfen Sie regelmäßig die Eigentümerschaft von Organisationen, Repositories, Webhooks, OAuth und Tokens.
Wenn Sie später SMTP, OAuth, LDAP oder OpenID Connect verbinden, behandeln Sie dies als separate Produktionsänderung. Testen Sie die Kontoverknüpfung, Wiederherstellung, Offboarding, Administratorzugang und Fehlverhalten, bevor Sie sich auf die Integration verlassen. Das Basisimage enthält diese Dienste oder deren Anmeldeinformationen nicht.
Was muss ein Gitea-Backup schützen?
Ein vollständiges Gitea-Backup muss die Datenbank, Git-Repositories, Konfiguration, Anwendungsg Geheimnisse und alle Anhänge, LFS-Objekte, Pakete, Releases, Avatare oder andere gespeicherte Daten, die Ihre Instanz verwendet, schützen. Es reicht nicht aus, nur die Git-Repositories zu kopieren, um Benutzer, Berechtigungen, Probleme, Pull-Requests, Tokens, Webhooks und Dienstkonfigurationen wiederherzustellen.
Die offizielle Gitea-Backup- und Wiederherstellungsdokumentation beschreibt den gitea dump-Workflow und warnt, dass der Dienst mehrere Datenschichten enthält, die zusammen geändert werden können. Ein konsistentes Backup erfordert Koordination; eine Anwendungsdatenbank, die angibt, dass eine Repository-Operation abgeschlossen wurde, während die Repository-Kopie einen früheren Zustand erfasst hat, kann einen unvollständigen Wiederherstellungspunkt erzeugen.
Ihr Backup-Plan sollte Folgendes definieren:
| Schicht | Beispiele | Warum es wichtig ist |
|---|---|---|
| Datenbank | Benutzer, Berechtigungen, Probleme, Pull-Requests, Einstellungen, Tokens | Stellt den Anwendungszustand und die Beziehungen wieder her |
| Git-Repositories | Commits, Branches, Tags, Git-Objekte | Erhält die Quellhistorie |
| Konfiguration und Geheimnisse | Öffentliche URL, Dienstkonfiguration, SECRET_KEY, interne Tokens | Hält verschlüsselte Daten lesbar und das Verhalten konsistent |
| Anwendungsdaten | Anhänge, Avatare, LFS, Pakete, Release-Assets, Indizes | Erhält Inhalte außerhalb normaler Git-Objekte |
| Wiederherstellungsverfahren | Versionen, Eigentum, Hook-Regeneration, Verifizierungsschritte | Verwandelt gespeicherte Dateien in einen nutzbaren wiederhergestellten Dienst |
Bewahren Sie Wiederherstellungskopien außerhalb des VPS auf. Verschlüsseln Sie sie, wenn sie privaten Quellcode, Anmeldeinformationen, Tokens, persönliche Daten oder interne Konfiguration enthalten. Halten Sie mehr als einen Wiederherstellungspunkt, überwachen Sie den Abschluss der Backups und testen Sie eine Wiederherstellung in einer separaten Umgebung.
Ein normaler VPS-Neustart beweist die Beständigkeit, nicht die Wiederherstellbarkeit. Er schützt nicht vor versehentlichem Löschen, Repository-Korruption, einem fehlgeschlagenen Upgrade, Anmeldeinformationskompromittierung, Dateisystemverlust, VPS-Löschung oder einem Angreifer, der sowohl die Live-Daten als auch lokale Backup-Dateien löscht.
Für die breitere Serverwartungsbasis rund um SSH, Patching, Überwachung und Wiederherstellungsverantwortung siehe VPS-Management: Praktischer Leitfaden.
Wie sollten Sie Gitea aktualisieren?
Aktualisieren Sie Gitea als kontrollierte Anwendungsänderung: Lesen Sie die Versionshinweise, erstellen Sie ein wiederherstellbares Backup, bewahren Sie den Bereitstellungstyp und überprüfen Sie anschließend die Repositories und die Authentifizierung. Das Image verwendet eine feste stabile Version anstelle eines schwebenden Tags, sodass ein Neustart die Anwendungsversion nicht stillschweigend ändert.
Vor einem Update:
- Lesen Sie die Gitea-Version und die Upgrade-Hinweise für die Quell- und Zielversionen.
- Bestätigen Sie den unterstützten Upgrade-Pfad, anstatt über Versionen hinweg zu springen, ohne sie zu überprüfen.
- Erstellen und überprüfen Sie ein Off-Server-Backup.
- Dokumentieren Sie das aktuelle Container-Image, die Konfiguration, die öffentliche URL, die SSH-Einstellungen und den Speicherbesitz.
- Planen Sie ein Wartungsfenster, da Datenbankmigrationen oder Backup-Konsistenz möglicherweise Ausfallzeiten erfordern.
Nach einem Update:
- Bestätigen Sie, dass der Container einen gesunden Zustand erreicht.
- Melden Sie sich mit einem normalen Konto und einem Administratorkonto an.
- Klonen, ziehen und pushen Sie über HTTP(S) und SSH.
- Öffnen Sie ein Problem und einen Pull-Request in einem Test-Repository.
- Überprüfen Sie Webhooks, Pakete, LFS, E-Mail und Authentifizierungsintegrationen, die Ihre Instanz tatsächlich verwendet.
- Überprüfen Sie, ob die generierten Klon-URLs weiterhin die richtige Domain und den richtigen Port verwenden.
- Bestätigen Sie, dass Benutzer, Repositories, Konfiguration und Geheimnisse die Änderung überstanden haben.
Wechseln Sie nicht leichtfertig zwischen Giteas rootvollen und rootlosen Container-Layouts; die offizielle Docker-Dokumentation weist darauf hin, dass sich deren Speicher- und SSH-Verhalten unterscheiden. Bewahren Sie das Bereitstellungsmodell, das vom Anwendungsimage ausgewählt wurde, es sei denn, Sie haben einen Migrations- und Rollback-Plan.
Wie viel VPS-Kapazität benötigt Gitea?
Die Kapazität von Gitea hängt von der Benutzerkonkurrenz, der Anzahl und Größe der Repositories, den Git-Betriebsmustern, Paketen, LFS, Indizierung, Automatisierung und den Anforderungen an die Datenspeicherung ab. Wählen Sie einen geeigneten Plan im Kaufprozess, überwachen Sie die tatsächliche Arbeitslast und wechseln Sie zu einer größeren Konfiguration, wenn anhaltender CPU-, Speicher-, Disk- oder I/O-Druck auftritt.
Das offizielle Gitea-Projekt beschreibt eine Installation für kleine Teams als relativ leichtgewichtig, aber diese Aussage definiert nicht die Kapazität jeder Repository-Arbeitslast. Große Monorepositories, häufige Klone, große binäre Assets, Paketlagerung, Suchindizierung und automatisierte Jobs können das Ressourcenprofil erheblich verändern.
| Arbeitslast | Kapazitätsüberlegung |
|---|---|
| Einige kleine Quell-Repositories | Geeignet für eine Eingangsvalidierungs-Arbeitslast |
| Kleines Entwicklungsteam | Gleichzeitige Web- und Git-Operationen messen |
| Große Repository-Historie | Planen Sie Speicherplatz, Backup-Zeit und Klonverkehr |
| Git LFS oder Paket-Registry | Speicher und Übertragung getrennt von normalen Git-Objekten planen |
| Viele Webhooks oder Integrationen | Warten Sie Warteschlangen, Fehler und Verfügbarkeit downstream |
| Gitea Actions | Runner-Kapazität ist separat und nicht im Basisimage enthalten |
| Externe Datenbank oder Objektspeicher | Erfordert eine separat gestaltete und betriebene Architektur |
Beobachten Sie den Speicher-Druck, die CPU-Sättigung, die Dateisystemkapazität, die Inode-Nutzung, das SQLite-Sperrverhalten, Container-Neustarts, die Anforderungslatenz, fehlgeschlagene Git-Operationen, die Backup-Dauer und die Wiederherstellungsdauer. Die minimale Kaufgrenze ist ein validierter Ausgangspunkt, kein Versprechen für unbegrenzte Repositories oder Benutzer.
Häufige Fehler, die vermieden werden sollten
Die meisten frühen Gitea-Fehler resultieren daraus, dass ein vorinstallierter Repository-Dienst als vollständig verwaltete Plattform behandelt wird. Vermeiden Sie diese Fehler:
- Ein Installationsassistent bleibt exponiert. Verwenden Sie den SSH-Administrator-Setup-Prozess und halten Sie die Installationssperre aktiviert.
- Öffnen der öffentlichen Registrierung ohne einen Missbrauchsplan. Halten Sie die Registrierung deaktiviert, es sei denn, die offene Anmeldung ist beabsichtigt.
- Port
3000als öffentliches HTTP exponieren. Halten Sie ihn im Loopback und fügen Sie eine Domain mit vertrauenswürdigem HTTPS hinzu, bevor Sie routinemäßig Web- und HTTPS Git verwenden. - Port
2222mit VPS-Shell-Zugriff verwechseln. Es ist der Gitea SSH Git-Endpunkt und bietet keine Server-Shell. - Eine Administrator-Konto teilen. Verwenden Sie individuelle Konten und das geringste Privileg.
- Tokens in der Shell-Historie oder in Repository-Dateien speichern. Verwenden Sie einen geeigneten Anmeldeinformations- oder geheimen Speicher.
- Nur Git-Repositories sichern. Schützen Sie auch die Datenbank, Konfiguration, Geheimnisse, Anhänge, LFS, Pakete und das Wiederherstellungsverfahren.
- Das einzige Backup auf demselben VPS aufbewahren. Bewahren Sie verschlüsselte Wiederherstellungskopien außerhalb des Servers auf.
- Ein schwebendes Container-Tag verwenden. Fixieren Sie die getestete stabile Version und aktualisieren Sie absichtlich.
- Annehmen, dass die minimale Kapazität CI oder große Binärdateien abdeckt. Runner, Pakete, LFS, Monorepositories und hohe Konkurrenz erfordern eine separate Dimensionierung.
- Die öffentliche URL ändern, ohne Gitea zu aktualisieren. Überprüfen Sie
ROOT_URL, Domain, SSH-Domain, Klon-Links, Rückrufe und Webhooks. - Aktualisieren, ohne einen Wiederherstellungstest durchzuführen. Ein Backup, das noch nie wiederhergestellt wurde, ist ein unüberprüfter Wiederherstellungsplan.
FAQ
Kann ich Gitea selbst hosten, ohne es manuell zu installieren?
Ja. Das VoyraCloud Gitea-Anwendungsimage bietet eine vorinstallierte Community Edition-Instanz auf einem geeigneten Cloud VPS oder Residential IP VPS. Sie erstellen weiterhin den ersten Administrator, konfigurieren den Repository-Zugriff, verbinden eine Domain und HTTPS, verwalten Benutzer und sind für Updates und Backups verantwortlich.
Warum wird der erste Administrator über SSH erstellt?
SSH hält den Schritt zur Administratorerstellung hinter dem Zugriff auf den VPS und verhindert, dass ein Internetbesucher einen exponierten Installationsassistenten beansprucht. Die öffentliche Installationsseite ist vor der Lieferung gesperrt, und der Setup-Befehl verweigert die Erstellung eines weiteren Administrators, nachdem bereits einer existiert.
Kann ich Port 3000 direkt ins Internet exponieren?
Nein. Die Anwendung bindet Port 3000 an die Loopback-Schnittstelle des VPS, und der erste Login verwendet einen SSH-Tunnel. Verbinden Sie eine Domain, konfigurieren Sie einen Reverse-Proxy und browser-vertrauenswürdiges HTTPS und aktualisieren Sie Giteas öffentliche URL-Einstellungen, bevor Sie den Webdienst veröffentlichen.
Was ist der Unterschied zwischen VPS SSH und Gitea SSH Git?
VPS SSH verwaltet den Linux-Server, während Gitea SSH Git Repository-Daten mithilfe von Schlüsseln überträgt, die an Gitea-Konten angehängt sind. Der VPS verwendet den für die Ressource angezeigten SSH-Host und -Port; Gitea SSH Git verwendet den git-Benutzer und den Port 2222.
Sollte ich ein Passwort oder Token für HTTPS Git verwenden?
Verwenden Sie ein persönliches Zugriffstoken mit nur den Berechtigungen, die der Client oder die Integration benötigt. Speichern Sie es in einem geeigneten Anmeldeinformationshelfer, anstatt es in einem Repository, Skript oder einem Eintrag in der Shell-Historie einzubetten.
Ist die öffentliche Benutzerregistrierung aktiviert?
Nein. Das Anwendungsimage deaktiviert die Selbstregistrierung standardmäßig. Der Administrator kann genehmigte Benutzer erstellen oder die Registrierungsrichtlinie absichtlich ändern, nachdem er Missbrauch, E-Mail-Verifizierung und Anforderungen an die Zugriffskontrolle bewertet hat.
Beinhaltet das Image Gitea Actions-Runners?
Nein. Das Basisimage provisioniert oder betreibt keine Actions-Runners. Die Ausführungskapazität von Runnern, Isolation, Geheimnisse, Netzwerkzugang und Wartung erfordern ein separates Design.
Was muss ich sichern?
Schützen Sie die Datenbank, Git-Repositories, Konfiguration, Anwendungsg Geheimnisse, Anhänge, LFS-Objekte, Pakete, Releases und alle anderen gespeicherten Anwendungsdaten. Halten Sie Kopien außerhalb des VPS und testen Sie eine vollständige Wiederherstellung.
Aktualisiert VoyraCloud Gitea automatisch?
Nein. Neue VPS-Ressourcen erhalten die stabile Version, die für das Image genehmigt ist, während jeder Eigentümer spätere Updates kontrolliert. Lesen Sie die offiziellen Upgrade-Hinweise, erstellen Sie ein wiederherstellbares Backup und testen Sie Git- und Authentifizierungs-Workflows nach jeder Änderung.
Ist Residential IP VPS für Gitea erforderlich?
Nein. Cloud VPS ist die normale allgemeine Wahl für einen Quellcode-Dienst. Residential IP VPS wird ebenfalls technisch unterstützt, wenn eine breitere Arbeitslast speziell seine Netzwerkmerkmale benötigt, aber die Residential-Identität verbessert das normale Git-Hosting nicht von sich aus.
Fazit
Das Selbsthosting von Gitea auf einem VPS gibt Entwicklern und kleinen Teams die Kontrolle über Repositories, Konten, Kollaborationsdaten, Netzwerkzugang, Updates und Wiederherstellung. Das VoyraCloud-Anwendungsimage verkürzt die anfängliche Bereitstellung, indem es eine feste stabile Gitea-Umgebung mit einer gesperrten Installationsseite, privater Erstadministrator-Einrichtung, HTTPS- und SSH-Git-Zugriff sowie persistenten lokalen Daten bereitstellt.
Dieser Ausgangspunkt benötigt weiterhin einen Eigentümer. Fügen Sie vertrauenswürdiges HTTPS hinzu, verwenden Sie individuelle Konten und bereichsspezifische Anmeldeinformationen, halten Sie die Registrierung in Übereinstimmung mit Ihrer Zugriffspolitik, überwachen Sie die Kapazität, fixieren Sie Updates und pflegen Sie getestete Off-Server-Backups, bevor Sie den Dienst als kritische Infrastruktur behandeln.
Für die Domain- und Reverse-Proxy-Schicht vor dem Dienst siehe den Leitfaden zu Nginx Proxy Manager auf einem VPS.
Verwenden Sie das VoyraCloud-Anwendungsimage für Gitea, um von einer vorinstallierten VPS-Umgebung aus zu beginnen und Ihren Quellcode-Dienst unter Ihrer Kontrolle zu halten.