J'ai abandonné GitHub et j'ai auto-hébergé ma propre alternative privée

J'adore GitHub et je l'utilise depuis de très nombreuses années. Cependant, GitHub n'est pas toujours le meilleur choix pour la révision de code. Lorsque j'ai commencé à créer des applications privées, j'ai décidé de rechercher des alternatives et j'ai fini par auto-héberger mon propre serveur privé basé sur git.

GitHub est idéal pour les projets de grande envergure ou publics

J'adore trouver des logiciels open source gratuits sur GitHub.

Écoutez, GitHub est génial. C'est une ressource fantastique pour les projets open source, et c'est également un excellent référentiel de logiciels open source gratuits. J'utilise GitHub depuis la majeure partie des 15 dernières années à différents titres.

De la création de ROM Android au déploiement de projets entièrement open source que j'utilise dans mon homelab, GitHub occupe une place particulière dans mon cœur. Il s'agit d'une plate-forme simple qui offre aux utilisateurs un emplacement central pour rechercher des logiciels et est devenue une référence en matière de révision de code et de logiciels open source, même pour les grandes entreprises comme Apple ou Microsoft.

GitHub propose des projets « privés », mais la confidentialité n'est pas garantie

Les projets privés sont aussi privés que votre compte GitHub.

À l'époque où je faisais la majorité de mes contributions à GitHub il y a plusieurs années, GitHub facturait en fait les référentiels privés. C'était l'une des principales raisons d'obtenir un forfait GitHub payant : pouvoir avoir des dépôts privés. En 2019, GitHub a levé cette restriction et a commencé à autoriser les utilisateurs gratuits à créer des référentiels privés.

Il s'agit d'une fonctionnalité énorme si vous ne saviez pas que GitHub proposait des référentiels privés gratuits. Avoir un site massif comme GitHub pour gérer vos projets est fantastique, et ajouter des contributeurs est super simple. Cependant, les projets sur GitHub ne sont pas toujours « 100 % privés ».

GitHub est peut-être lui-même une entreprise privée, mais elle appartient en réalité à Microsoft. Cela peut poser problème à certaines personnes. Tout le code stocké sur GitHub est protégé par le cryptage TLS lors du téléchargement, mais il n'est pas crypté davantage. Techniquement, GitHub et sa société mère Microsoft peuvent accéder à votre code à tout moment, même si un référentiel est marqué privé.

Ce n'est peut-être pas un gros problème pour beaucoup, mais si vous avez du code auquel vous ne voulez vraiment pas que quiconque accède, le stocker sur des serveurs auxquels d'autres personnes pourraient accéder – soit par désir, soit par ordre légal – pourrait poser un problème. C'est pourquoi une partie de mon code ne réside tout simplement pas sur GitHub.

Les applications que j'écris pour lesquelles je souhaite conserver 100 % de propriété sur le code du début à la fin, je refuse de les mettre sur GitHub. Il y a tout simplement trop de risques pour que j'y héberge le code. Code public que je souhaite partager avec le monde ? Cela appartient à GitHub, et je le publierai volontiers à la vue de tous.

L'auto-hébergement de ma propre instance GitLab me donne un contrôle total sur les projets

Je suis responsable de la sécurité de mon serveur domestique.

Le code que je souhaite garder en sécurité se trouve sur mon propre serveur dans ma propre maison. J'ai choisi d'utiliser GitLab comme interface git sur le serveur, et je ne le regrette absolument pas. Bien que GitLab propose des plans hébergés et gérés, il offre également la possibilité de s'auto-héberger. GitLab possède bon nombre des mêmes fonctionnalités que GitHub, notamment le suivi des problèmes, la fonctionnalité CI/CD, les webhooks, etc.

Avec GitLab, je peux techniquement également héberger des référentiels publics, mais je choisis de tout garder privé pour mon seul utilisateur sur la plateforme. Le service étant hébergé chez moi, je pourrais choisir de bloquer l'accès au réseau externe, de l'ouvrir via quelque chose comme Tailscale ou Cloudflare Tunnels, ou de le placer derrière un proxy inverse. C'est moi qui choisis le degré de sécurité des données.

Comment démarrer avec la CLI de GitLab pour gérer DevOps depuis votre terminal

GitLab est la source de vérité pour de nombreuses équipes de développement. Cependant, l'accès aux données GitLab nécessite généralement un changement de contexte vers un navigateur Web ou des interactions API délicates. Il existe désormais une CLI officielle qui vous permet de gérer les processus DevOps sans quitter votre terminal.

De plus, je suis le seul à disposer des clés de cryptage et de l'accès physique au serveur. Les données que j’y stocke sont les miennes et les miennes seules. Cela peut paraître un peu paranoïaque, mais je ne veux pas que quelqu'un d'autre voie le code source de certains des programmes sur lesquels je travaille. Je passe beaucoup de temps à développer certains programmes et je souhaite qu'ils restent les miens.

Quelqu'un pourrait-il procéder à une ingénierie inverse des applications que je publie pour trouver le code source ? J'en suis sûr, mais cela demande beaucoup plus de recherches et de travail que de simplement tomber sur un dépôt que quelqu'un a oublié de marquer comme privé. Ou, pire encore, que quelqu'un s'est introduit par effraction parce qu'un compte en ligne avait été compromis.

Envie d'un Homelab privé ? Mettez ces 12 applications en haut de votre liste

Le nuage est froid, jusqu'à ce qu'il fuit.

En ce qui concerne mes référentiels privés, j'aime simplement être celui qui contrôle leur sécurité, et non quelqu'un d'autre. GitHub fonctionne bien pour de nombreuses personnes et les dépôts privés peuvent faire exactement ce dont vous avez besoin.

Cependant, en fin de compte, votre code est aussi sécurisé que votre compte GitHub (ou GitHub lui-même… ou même Microsoft lui-même), avec peu de choses à faire si quelque chose est compromis.