Comment auto-héberger Gitea sur un VPS

Vous pouvez auto-héberger Gitea sur un VPS VoyraCloud en sélectionnant l'image d'application préinstallée, en créant le premier administrateur via SSH, puis en utilisant l'interface web, Git HTTPS ou Git SSH pour vos dépôts. L'image supprime l'étape d'installation manuelle, tandis que la politique de compte, les domaines, HTTPS, l'accès aux dépôts, les mises à jour, les sauvegardes et la réponse aux incidents restent sous votre contrôle.

TL;DR

L'image d'application VoyraCloud Gitea fournit une instance de Gitea Community Edition préinstallée sur Cloud VPS et Residential IP VPS.
La page d'installation est verrouillée avant la livraison. Créez le premier administrateur via la commande SSH indiquée dans les détails de votre ressource, et non via un assistant d'installation exposé publiquement.
Le port 3000 est lié à l'interface de boucle locale du VPS. Utilisez la commande SSH Tunnel dans les détails de la ressource pour la première connexion web ; il n'est pas exposé comme HTTP public.
Ajoutez un domaine, un proxy inverse et un HTTPS de confiance avant de publier l'interface web ou d'utiliser Git HTTPS. Gitea SSH Git utilise le port public séparé 2222 après que vous ayez ajouté une clé publique à votre compte.
L'enregistrement de nouveaux utilisateurs est désactivé par défaut. L'administrateur décide s'il doit créer des utilisateurs manuellement ou modifier la politique d'enregistrement.
Les dépôts, comptes, problèmes, demandes de tirage, paquets, pièces jointes, configuration et secrets persistent lors d'un redémarrage normal du VPS, mais la persistance du redémarrage n'est pas une sauvegarde hors serveur.
VoyraCloud ne met pas automatiquement à niveau, ne sauvegarde pas, ne surveille pas et n'administre pas l'instance Gitea après la livraison.

Qu'est-ce que Gitea ?

Gitea est un service de développement logiciel open-source pour héberger des dépôts Git et collaborer sur du code source. Il fournit une interface web autour des flux de travail Git standard, ainsi que des comptes utilisateurs, des organisations, des permissions de dépôt, des demandes de tirage, des problèmes, des projets, des wikis, des versions, des paquets, des webhooks et un accès API.

La documentation officielle de Gitea décrit l'installation et l'administration pour les équipes qui souhaitent faire fonctionner leur propre service. L'auto-hébergement est utile lorsque vous souhaitez que le service de dépôt, l'emplacement de stockage, la politique de compte, l'accès réseau, le timing des mises à jour et le processus de sauvegarde soient sous votre propre administration.

Un VPS Gitea est un choix pratique pour :

Un développeur qui souhaite des dépôts privés sur un serveur personnel.
Une petite équipe qui a besoin d'hébergement Git, de révisions de code, de problèmes et de permissions d'organisation.
Une agence qui garde des dépôts séparés pour les projets clients.
Une équipe d'infrastructure qui connecte des dépôts à des systèmes de déploiement via des clés SSH, des jetons d'accès, des webhooks ou des API.
Un laboratoire ou un environnement interne qui a besoin d'une alternative légère à une plateforme de développement logiciel plus grande.

L'auto-hébergement ne rend pas les opérations de dépôt sans maintenance. Quelqu'un doit toujours s'occuper de la sécurité du système d'exploitation, des mises à jour de Gitea, de la politique d'authentification, du HTTPS, des sauvegardes, de la croissance du stockage, de la prévention des abus et des tests de récupération.

Comment commencer avec l'image VoyraCloud Gitea ?

Le chemin de déploiement le plus rapide consiste à créer un VPS VoyraCloud pris en charge avec l'image Gitea et à exécuter la commande de configuration de l'administrateur privé à partir des détails de la ressource. Vous n'avez pas besoin d'installer Docker, Gitea ou la base de données initiale manuellement.

Ouvrez la page VoyraCloud pour Gitea à partir du lien ci-dessus et continuez avec le processus d'achat du VPS.
Sélectionnez une configuration de Cloud VPS ou de Residential IP VPS éligible. Le Cloud VPS est l'option polyvalente pour l'hébergement Git ; le Residential IP VPS reste disponible lorsque votre charge de travail plus large nécessite spécifiquement les caractéristiques réseau de ce produit.
Choisissez n'importe quelle région actuellement proposée par le produit VPS sélectionné et confirmez que Gitea est sélectionné dans la section Images.
Créez le VPS et attendez que la ressource et l'application soient prêtes.
Ouvrez les détails de la ressource et localisez la section Application.
Copiez la commande de configuration de l'administrateur. Elle suit ce modèle :

ssh -t -p <ssh-port> <ssh-user>@<server-ip> 'sudo /usr/local/sbin/voyra-gitea-create-admin'

7. Exécutez la commande depuis votre terminal et entrez le nom d'utilisateur et l'email de l'administrateur. L'interface CLI officielle de Gitea génère un mot de passe aléatoire à usage unique de 24 caractères et l'affiche uniquement dans la session SSH actuelle.

8. Copiez la commande SSH Tunnel depuis la section Application et gardez cette session terminal ouverte. Elle suit ce modèle :

ssh -N -L 3000:127.0.0.1:3000 -p <ssh-port> <ssh-user>@<server-ip>

9. Ouvrez l'URL d'accès local dans votre navigateur :

http://127.0.0.1:3000

10. Connectez-vous avec le compte administrateur et le mot de passe à usage unique, puis définissez un nouveau mot de passe lorsque Gitea exige le changement.

11. Créez un dépôt de test privé, ajoutez une clé publique SSH et vérifiez un clonage et un push SSH.

12. Connectez votre domaine, configurez un HTTPS de confiance, mettez à jour les paramètres d'URL publique de Gitea et confirmez que les liens de clonage HTTPS générés utilisent l'adresse prévue.

13. Redémarrez le VPS une fois et vérifiez que Gitea revient automatiquement avec l'administrateur, le dépôt de test, l'historique des commits, les clés et les paramètres intacts.

14. Créez une sauvegarde hors serveur et effectuez une restauration de test avant de compter sur l'instance pour un code source important.

La commande de configuration est intentionnellement séparée de la page web. L'assistant d'installation public est déjà verrouillé, donc un visiteur d'internet ne peut pas revendiquer une nouvelle instance en créant le premier administrateur avant le propriétaire. La commande s'arrête également si un administrateur existe déjà.

Utilisez le nom d'utilisateur SSH et le port indiqués pour votre ressource VPS. Ne supposez pas que chaque serveur utilise root ou le port 22. La connexion SSH VPS utilisée pour l'administration est également différente du point de terminaison SSH Git de Gitea sur le port 2222.

Que comprend l'image d'application ?

L'image d'application Gitea comprend un point de départ unique et persistant, et non un service d'hébergement de code source géré. La limite de livraison détermine ce que vous devez configurer avant une utilisation régulière par l'équipe.

Livré par l'image d'application	Géré par l'utilisateur ou non inclus
Version stable de Gitea Community Edition approuvée pour l'image	Mises à niveau automatiques de Gitea
Environnement VPS basé sur Ubuntu	Administration du système d'exploitation gérée
Gitea fonctionnant dans le conteneur officiel avec une base de données SQLite locale	Service PostgreSQL ou MySQL externe
Page d'installation verrouillée	Assistant d'installation web public
Commande SSH privée pour créer le premier administrateur	Administrateur précréé ou mot de passe fixe
Enregistrement désactivé par défaut	Provisionnement automatique des membres de l'équipe
Backend web sur le port de boucle locale `3000`	Exposition HTTP publique, enregistrement de domaine, proxy inverse et HTTPS automatique
SSH Git sur le port `2222`	Clés SSH utilisateur préinstallées
Dépôts persistants, base de données, configuration et données d'application	Sauvegardes automatiques hors serveur
Récupération de service après un redémarrage normal du VPS	Haute disponibilité ou basculement automatique
Fonctionnalités de collaboration standard de Gitea	Runners gérés, capacité CI, SMTP, OAuth, LDAP ou stockage externe

L'image n'inclut pas de dépôts d'exemple, d'organisations, d'utilisateurs, de runners, de paquets, de références tierces, de livraison d'email, d'un domaine ou d'un certificat de confiance pour le navigateur. Elle n'expose également pas les secrets de l'application dans les détails de la ressource.

Comment fonctionne la configuration sécurisée du premier administrateur ?

Le premier administrateur est créé via une session SSH VPS authentifiée, tandis que la page d'installation publique de Gitea reste verrouillée. Cela empêche la course commune dans laquelle un installateur web non initialisé est accessible depuis internet et un visiteur non intentionnel termine la configuration en premier.

L'image d'application prépare la base de données et la configuration avant la livraison. Elle active le verrou d'installation de Gitea et désactive l'enregistrement public des utilisateurs. La commande de configuration de l'administrateur exécute ensuite la commande administrative officielle de Gitea à l'intérieur de l'environnement de l'application.

Le processus de configuration doit avoir ces propriétés :

Il demande le nom d'utilisateur et l'email de manière interactive.
Il indique à l'interface CLI officielle de Gitea de générer un mot de passe aléatoire de 24 caractères au lieu de placer votre mot de passe choisi dans un argument de ligne de commande.
Il affiche le mot de passe à usage unique uniquement dans le terminal SSH actuel et ne l'écrit pas dans l'historique de la shell, un fichier ou un journal.
Il exige un changement de mot de passe lors de la première connexion web.
Il refuse de créer un autre administrateur après que le premier administrateur existe.
Il ne génère pas de jeton d'accès personnel ou de clé SSH pour vous.
Il n'imprime pas les secrets internes de Gitea.

Après vous être connecté, examinez l'administration du site et la politique d'enregistrement des utilisateurs. L'enregistrement est désactivé par défaut afin que les utilisateurs inconnus d'internet ne puissent pas créer de comptes. Vous pouvez créer des utilisateurs approuvés depuis l'interface d'administration ou modifier la politique si l'enregistrement ouvert est une exigence intentionnelle et que vous avez un plan de contrôle des abus.

Ne pas envoyer le mot de passe à usage unique ou final de l'administrateur par chat, ticket ou transcription de shell partagée. Fermez la session SSH initiale après avoir changé le mot de passe. Ajoutez un deuxième administrateur uniquement lorsque la propriété opérationnelle l'exige, et utilisez un compte normal séparé pour le travail Git de routine lorsque cela est pratique.

Comment HTTPS Git et SSH Git diffèrent-ils ?

HTTPS Git utilise le point de terminaison web de Gitea derrière votre domaine HTTPS de confiance, tandis que SSH Git utilise un service SSH Gitea dédié et une clé publique au niveau du compte. Les deux prennent en charge les opérations normales de clonage, de récupération, de tirage et de poussée, mais leur configuration d'authentification et de transport diffère.

Méthode	Modèle d'adresse initiale	Authentification	Meilleure utilisation après la configuration
Interface web initiale	`http://127.0.0.1:3000` via SSH Tunnel	Nom d'utilisateur et mot de passe Gitea	Première connexion, changement de mot de passe et configuration privée
Interface web régulière	`https://git.example.com`	Nom d'utilisateur et mot de passe Gitea	Navigation dans les dépôts et administration après la configuration du domaine
HTTPS Git	`https://git.example.com/<owner>/<repo>.git`	Préférez un jeton d'accès personnel pour les clients Git	Transport Git basé sur le web après la configuration du domaine et du HTTPS de confiance
SSH Git	`ssh://git@<server-ip>:2222/<owner>/<repo>.git`	Clé publique SSH ajoutée au compte Gitea	Pratique pour les clients Git des développeurs et l'automatisation utilisant des clés gérées
SSH système VPS	Hôte et port spécifiques à la ressource	Clé SSH VPS ou identifiant de serveur actuel	Administration du serveur et configuration du premier administrateur, pas d'accès au dépôt

Pour SSH Git :

Créez ou choisissez une clé SSH sur votre station de travail.
Connectez-vous à Gitea et ajoutez la clé publique dans les paramètres du compte.
Copiez l'adresse de clonage SSH depuis la page du dépôt.
Vérifiez l'empreinte de l'hôte lors de la première connexion au lieu d'accepter une clé inattendue sans la vérifier.
Conservez la clé privée sur le client et protégez-la avec des permissions de fichier appropriées et, le cas échéant, une phrase de passe.

Gitea SSH Git ne devrait pas demander le mot de passe web de Gitea. Le port 2222 appartient au service de dépôt ; il ne fournit pas de shell serveur.

Pour HTTPS Git, créez un jeton d'accès personnel avec uniquement les permissions nécessaires pour ce client ou cette intégration. Évitez de mettre un jeton directement dans une commande qui restera dans l'historique de la shell. Utilisez votre helper d'identifiants Git ou un magasin secret approprié à votre système d'exploitation.

Pourquoi devriez-vous ajouter un domaine et HTTPS ?

Un domaine et un HTTPS de confiance pour le navigateur protègent les identifiants web et le trafic Git HTTPS et donnent à l'instance une identité publique stable. L'image garde le port 3000 sur l'interface de boucle locale du VPS, donc le service web n'est pas accessible publiquement tant que vous ne configurez pas délibérément un proxy inverse.

Le guide officiel de Gitea sur les proxies inverses explique comment Gitea fonctionne derrière des proxies courants. Une configuration de production inclut normalement :

Un enregistrement DNS tel que git.example.com pointant vers le VPS.
Un proxy inverse écoutant sur les ports 80 et 443.
Un certificat TLS de confiance pour le domaine.
Une redirection HTTP vers HTTPS.
Des en-têtes d'hôte, d'adresse client et de protocole transférés qui correspondent à la configuration du proxy.
Les paramètres publics ROOT_URL et de domaine de Gitea mis à jour vers l'URL HTTPS finale.
SSH_DOMAIN et le port SSH affiché mis à jour afin que les instructions de clonage de dépôt restent précises.

Après avoir changé l'adresse, vérifiez tout ce qui suit :

La page de connexion se charge sans avertissement de certificat.
Les liens générés par Gitea utilisent le domaine HTTPS plutôt que l'ancienne adresse IP.
Le clonage et le push Git HTTP fonctionnent via HTTPS.
Les liens de clonage SSH affichent le bon domaine et le bon port.
Les webhooks et les URL de rappel OAuth, si configurés ultérieurement, utilisent l'adresse publique prévue.
Les grandes poussées ne échouent pas en raison des limites de corps ou de temps d'attente du proxy inverse.

L'image d'application n'enregistre pas le domaine ni n'émet le certificat pour vous. Ces étapes sont gérées par l'utilisateur car le nom d'hôte final et le compte DNS appartiennent au propriétaire du site.

Comment devriez-vous organiser les utilisateurs et l'accès aux dépôts ?

Utilisez des comptes individuels, des équipes d'organisation, des permissions de dépôt, des clés SSH et des jetons à portée plutôt que de partager une seule identité d'administrateur. Gitea peut héberger des dépôts privés et publics, mais l'administrateur doit décider qui peut découvrir, lire, écrire, examiner et administrer chaque ressource.

Une base pratique pour une petite équipe est :

Gardez l'enregistrement public désactivé à moins qu'il n'y ait une raison délibérée de l'ouvrir.
Donnez à chaque personne un compte individuel.
Réservez l'accès administrateur aux propriétaires de serveur et de service.
Créez des organisations pour les dépôts et des équipes pour les groupes de permissions.
Accordez la permission de dépôt la moins élevée nécessaire pour chaque rôle.
Utilisez la protection des branches et les règles de révision pour les branches importantes.
Utilisez des clés de déploiement ou des jetons d'accès personnels à portée pour l'automatisation plutôt qu'un mot de passe administrateur.
Supprimez rapidement les comptes, clés et jetons lorsque l'accès n'est plus requis.
Activez l'authentification à deux facteurs pour les utilisateurs privilégiés lorsque cela correspond à votre modèle d'accès.
Examinez périodiquement la propriété des organisations, des dépôts, des webhooks, des OAuth et des jetons.

Si vous connectez ultérieurement SMTP, OAuth, LDAP ou OpenID Connect, considérez cela comme un changement de production séparé. Testez le lien des comptes, la récupération, le départ, l'accès administrateur et le comportement en cas d'échec avant de compter sur l'intégration. L'image de base n'inclut pas ces services ni leurs identifiants.

Que doit protéger une sauvegarde Gitea ?

Une sauvegarde complète de Gitea doit protéger la base de données, les dépôts Git, la configuration, les secrets de l'application et toutes les pièces jointes, objets LFS, paquets, versions, avatars ou autres données stockées que votre instance utilise. Copier uniquement les dépôts Git ne suffit pas à reconstruire les utilisateurs, permissions, problèmes, demandes de tirage, jetons, webhooks et paramètres de service.

La documentation officielle de sauvegarde et de restauration de Gitea décrit le flux de travail gitea dump et avertit que le service contient plusieurs couches de données qui peuvent changer ensemble. Une sauvegarde cohérente nécessite une coordination ; une base de données d'application qui dit qu'une opération de dépôt est terminée alors que la copie du dépôt a capturé un état antérieur peut produire un point de récupération incomplet.

Votre plan de sauvegarde doit définir :

Couche	Exemples	Pourquoi c'est important
Base de données	Utilisateurs, permissions, problèmes, demandes de tirage, paramètres, jetons	Recrée l'état et les relations de l'application
Dépôts Git	Commits, branches, tags, objets Git	Préserve l'historique source
Configuration et secrets	URL publique, paramètres de service, `SECRET_KEY`, jetons internes	Garde les données chiffrées lisibles et le comportement cohérent
Données d'application	Pièces jointes, avatars, LFS, paquets, actifs de version, index	Préserve le contenu en dehors des objets Git normaux
Procédure de récupération	Versions, propriété, régénération de hooks, étapes de vérification	Transforme les fichiers stockés en un service restauré utilisable

Stockez les copies de récupération en dehors du VPS. Chiffrez-les lorsqu'elles contiennent du code source privé, des identifiants, des jetons, des données personnelles ou une configuration interne. Conservez plus d'un point de récupération, surveillez l'achèvement des sauvegardes et testez une restauration dans un environnement séparé.

Un redémarrage normal du VPS prouve la persistance, pas la récupérabilité. Cela ne protège pas contre la suppression accidentelle, la corruption de dépôt, une mise à niveau échouée, un compromis d'identifiants, une perte de système de fichiers, la suppression du VPS ou un attaquant supprimant à la fois les données en direct et les fichiers de sauvegarde locaux.

Pour la base de maintenance de serveur plus large autour de SSH, des correctifs, de la surveillance et de la propriété de récupération, voir Gestion VPS : Guide Pratique.

Comment devriez-vous mettre à jour Gitea ?

Mettez à jour Gitea comme un changement d'application contrôlé : lisez les notes de version, créez une sauvegarde restaurable, préservez le type de déploiement et vérifiez les dépôts et l'authentification par la suite. L'image utilise une version stable fixe plutôt qu'un tag flottant afin qu'un redémarrage ne change pas silencieusement la version de l'application.

Avant une mise à jour :

Lisez les notes de version et de mise à niveau de Gitea pour les versions source et cible.
Confirmez le chemin de mise à niveau pris en charge au lieu de sauter entre les versions sans révision.
Créez et vérifiez une sauvegarde hors serveur.
Enregistrez l'image de conteneur actuelle, la configuration, l'URL publique, les paramètres SSH et la propriété de stockage.
Planifiez une fenêtre de maintenance car les migrations de base de données ou la cohérence des sauvegardes peuvent nécessiter un temps d'arrêt.

Après une mise à jour :

Confirmez que le conteneur atteint un état sain.
Connectez-vous avec un compte normal et un compte administrateur.
Clonez, tirez et poussez via HTTP(S) et SSH.
Ouvrez un problème et une demande de tirage dans un dépôt de test.
Vérifiez les webhooks, les paquets, LFS, l'email et les intégrations d'authentification que votre instance utilise réellement.
Vérifiez que les URL de clonage générées utilisent toujours le bon domaine et le bon port.
Confirmez que les utilisateurs, dépôts, configuration et secrets ont survécu au changement.

Ne changez pas de manière désinvolte entre les mises en page de conteneur avec ou sans root de Gitea ; la documentation officielle de Docker note que leur comportement de stockage et SSH diffère. Préservez le modèle de déploiement sélectionné par l'image d'application à moins que vous n'ayez un plan de migration et de retour en arrière.

Quelle capacité VPS Gitea nécessite-t-il ?

La capacité de Gitea dépend de la concurrence des utilisateurs, du nombre et de la taille des dépôts, des modèles d'opérations Git, des paquets, de LFS, de l'indexation, de l'automatisation et des exigences de conservation des données. Choisissez un plan éligible dans le processus d'achat, surveillez la charge de travail réelle et passez à une configuration plus grande lorsque la pression CPU, mémoire, disque ou I/O est soutenue.

Le projet Gitea officiel décrit une installation pour petite équipe comme relativement légère, mais cette déclaration ne définit pas la capacité de chaque charge de travail de dépôt. De grands monorepositories, des clonages fréquents, de gros actifs binaires, le stockage de paquets, l'indexation de recherche et les travaux automatisés peuvent changer le profil des ressources de manière substantielle.

Charge de travail	Considération de capacité
Quelques petits dépôts source	Approprié pour une charge de validation d'entrée
Petite équipe de développement	Mesurer les opérations web et Git simultanées
Historique de dépôt important	Prévoir l'espace disque, le temps de sauvegarde et le trafic de clonage
Git LFS ou registre de paquets	Prévoir le stockage et le transfert séparément des objets Git normaux
Beaucoup de webhooks ou d'intégrations	Surveiller les files d'attente, les échecs et la disponibilité en aval
Gitea Actions	La capacité des runners est séparée et non incluse par l'image de base
Base de données externe ou stockage d'objets	Exige une architecture conçue et exploitée séparément

Surveillez la pression mémoire, la saturation CPU, la capacité du système de fichiers, l'utilisation des inodes, le comportement de verrouillage SQLite, les redémarrages de conteneurs, la latence des requêtes, les opérations Git échouées, la durée des sauvegardes et la durée des restaurations. Le seuil d'achat minimum est un point de départ validé, pas une promesse de dépôts ou d'utilisateurs illimités.

Erreurs courantes à éviter

La plupart des échecs précoces de Gitea proviennent du fait de traiter un service de dépôt préinstallé comme une plateforme entièrement gérée. Évitez ces erreurs :

Laisser un assistant d'installation exposé. Utilisez le flux de configuration de l'administrateur SSH et gardez le verrou d'installation activé.
Ouvrir l'enregistrement public sans un plan de contrôle des abus. Gardez l'enregistrement désactivé à moins que l'inscription ouverte ne soit intentionnelle.
Exposer le port 3000 comme HTTP public. Gardez-le sur la boucle locale et ajoutez un domaine avec HTTPS de confiance avant une utilisation web et Git HTTPS de routine.
Confondre le port 2222 avec l'accès shell VPS. C'est le point de terminaison SSH Git de Gitea et ne fournit pas de shell serveur.
Partager un compte administrateur unique. Utilisez des comptes individuels et le moindre privilège.
Mettre des jetons dans l'historique de la shell ou des fichiers de dépôt. Utilisez un magasin d'identifiants ou de secrets approprié.
Faire des sauvegardes uniquement des dépôts Git. Protégez également la base de données, la configuration, les secrets, les pièces jointes, LFS, les paquets et la procédure de récupération.
Conserver la seule sauvegarde sur le même VPS. Stockez des copies de récupération chiffrées en dehors du serveur.
Utiliser un tag de conteneur flottant. Fixez la version stable testée et mettez à jour délibérément.
Supposer que la capacité minimale couvre CI ou de gros binaires. Les runners, paquets, LFS, monorepositories et forte concurrence nécessitent un dimensionnement séparé.
Changer l'URL publique sans mettre à jour Gitea. Vérifiez ROOT_URL, domaine, domaine SSH, liens de clonage, rappels et webhooks.
Mettre à jour sans test de restauration. Une sauvegarde qui n'a jamais été restaurée est un plan de récupération non vérifié.

FAQ

Puis-je auto-héberger Gitea sans l'installer manuellement ?

Oui. L'image d'application VoyraCloud Gitea fournit une instance Community Edition préinstallée sur un Cloud VPS ou un Residential IP VPS éligible. Vous devez toujours créer le premier administrateur, configurer l'accès aux dépôts, connecter un domaine et HTTPS, gérer les utilisateurs et posséder les mises à jour et les sauvegardes.

Pourquoi le premier administrateur est-il créé via SSH ?

SSH garde l'étape de création de l'administrateur derrière l'accès au VPS et empêche un visiteur d'internet de revendiquer un assistant d'installation exposé. La page d'installation publique est verrouillée avant la livraison, et la commande de configuration refuse de créer un autre administrateur après qu'un existe déjà.

Puis-je exposer le port `3000` directement sur internet ?

Non. L'application lie le port 3000 à l'interface de boucle locale du VPS et la première connexion utilise un SSH Tunnel. Connectez un domaine, configurez un proxy inverse et un HTTPS de confiance, et mettez à jour les paramètres d'URL publique de Gitea avant de publier le service web.

Quelle est la différence entre VPS SSH et Gitea SSH Git ?

VPS SSH administre le serveur Linux, tandis que Gitea SSH Git transfère les données du dépôt en utilisant des clés attachées aux comptes Gitea. Le VPS utilise l'hôte SSH et le port indiqués pour la ressource ; Gitea SSH Git utilise l'utilisateur git et le port 2222.

Devrais-je utiliser un mot de passe ou un jeton pour HTTPS Git ?

Utilisez un jeton d'accès personnel avec uniquement les permissions nécessaires pour le client ou l'intégration. Stockez-le dans un helper d'identifiants approprié plutôt que de l'incorporer dans un dépôt, un script ou une entrée d'historique de shell.

L'enregistrement public des utilisateurs est-il activé ?

Non. L'image d'application désactive l'auto-enregistrement par défaut. L'administrateur peut créer des utilisateurs approuvés ou modifier délibérément la politique d'enregistrement après avoir évalué les abus, la vérification par email et les exigences de contrôle d'accès.

L'image inclut-elle des runners Gitea Actions ?

Non. L'image de base ne provisionne ni n'exploite les runners Actions. La capacité d'exécution des runners, l'isolation, les secrets, l'accès réseau et la maintenance nécessitent une conception séparée.

Que dois-je sauvegarder ?

Protégez la base de données, les dépôts Git, la configuration, les secrets de l'application, les pièces jointes, les objets LFS, les paquets, les versions et toutes les autres données d'application stockées. Gardez des copies en dehors du VPS et testez une restauration complète.

VoyraCloud met-il automatiquement à jour Gitea ?

Non. Les nouvelles ressources VPS reçoivent la version stable approuvée pour l'image, tandis que chaque propriétaire contrôle les mises à jour ultérieures. Lisez les notes de mise à niveau officielles, créez une sauvegarde restaurable et testez les flux de travail Git et d'authentification après chaque changement.

Un Residential IP VPS est-il requis pour Gitea ?

Non. Le Cloud VPS est le choix normal polyvalent pour un service de code source. Le Residential IP VPS est également techniquement pris en charge lorsque une charge de travail plus large nécessite spécifiquement ses caractéristiques réseau, mais l'identité résidentielle n'améliore pas l'hébergement Git normal par elle-même.

Conclusion

Auto-héberger Gitea sur un VPS donne aux développeurs et aux petites équipes le contrôle sur les dépôts, les comptes, les données de collaboration, l'accès réseau, les mises à jour et la récupération. L'image d'application VoyraCloud raccourcit le déploiement initial en livrant un environnement Gitea stable fixe avec une page d'installation verrouillée, une configuration privée du premier administrateur, un accès HTTPS et SSH Git, et des données locales persistantes.

Ce point de départ a toujours besoin d'un propriétaire. Ajoutez un HTTPS de confiance, utilisez des comptes individuels et des identifiants à portée, gardez l'enregistrement aligné avec votre politique d'accès, surveillez la capacité, fixez les mises à jour et maintenez des sauvegardes hors serveur testées avant de traiter le service comme une infrastructure critique.

Pour la couche de domaine et de proxy inverse devant le service, consultez le guide sur Nginx Proxy Manager sur un VPS.

Utilisez l'image d'application VoyraCloud pour Gitea pour commencer à partir d'un environnement VPS préinstallé tout en gardant votre service de code source sous votre contrôle.