La pile de productivité développeur auto-hébergée : remplacer GitHub, Vercel et Sentry sur un seul VPS en 2026

Aux tarifs affichés actuels, une équipe de 3 personnes utilisant GitHub Team, Vercel Pro, Sentry Team, Linear Basic et Notion Plus démarre à environ 158 $ par mois, avant 1Password, les frais à l'usage et les options. Une pile auto-hébergée bien cadrée peut réduire nettement cette facture, mais la comparaison honnête inclut un VPS plus grand que le plancher de laboratoire de 4 Go et le temps de maintenance que tout le monde oublie.

Ce guide s'adresse au développeur ou à la petite équipe qui a déjà conclu que « la facture SaaS est agaçante » et que « garder du code privé et des flux de travail de développement sur une infrastructure tierce met mal à l'aise », et qui veut maintenant savoir quoi exécuter précisément. La pile compte quatre couches : coder, construire et déployer, exécuter, documenter. Chaque couche reçoit un outil recommandé, une alternative, son coût en ressources et son mode de défaillance. Le périmètre est l'usage privé et en équipe sur un seul VPS. L'hébergement e-mail, le DNS, l'authentification des clients finaux et Kubernetes sont hors périmètre, pour des raisons que nous exposerons là où elles ont leur place.

La version courte

Si vous ne lisez que les puces :

• Code : Forgejo par défaut. N'utilisez GitLab CE que si vous voulez git, CI/CD, registre et tickets dans un seul produit ; la base actuelle de GitLab sur un nœud unique est de 16 Go de RAM, les 8 Go étant réservés aux environnements contraints en mémoire.
• Construire et déployer : 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.
• Exécutez : Vaultwarden pour les identifiants partagés, Uptime Kuma pour la supervision, GlitchTip pour le suivi des erreurs, et Portainer ou Dockge pour la gestion des conteneurs. GlitchTip est un déploiement bien plus léger que Sentry auto-hébergé, dont le minimum officiel est de 16 Go de RAM plus 16 Go de swap.
• Documenter : Docmost pour la documentation et OpenProject (ou Plane) pour le suivi des tickets. AFFiNE convient aux équipes qui préfèrent un modèle Notion façon canevas.
• Dimensionnement : Considérez 4 Go comme une taille de laboratoire pour quelques services légers, 8 Go comme un pilote réduit sans OpenProject, Plane ni builds locaux, et 16 Go comme le point de départ pratique de la pile complète fondée sur Forgejo décrite ici. La base 8 vCPU / 16 Go de GitLab s'applique à GitLab lui-même : une pile monobloc fondée sur GitLab exige donc de la capacité supplémentaire ou des tests de charge dédiés.
• Là où elle perd : Les projets open source publics avec des contributeurs externes. L'effet de réseau de GitHub est réel, et l'auto-hébergement vous coûte en visibilité.

Prérequis

Avant d'aller plus loin, ce guide suppose :

• Un VPS Linux avec Docker et Docker Compose installés. Prévoyez environ 16 Go de RAM pour la pile complète fondée sur Forgejo ; 8 Go conviennent à un pilote réduit qui laisse de côté les outils de gestion de projet les plus lourds et les builds locaux.
• De 30 à 60 minutes d'attention par couche pour le déploiement initial.
• De l'aisance à lire un fichier Compose et à ajuster des variables d'environnement.
• La volonté de tenir une fenêtre de mise à jour régulière, d'appliquer rapidement les correctifs de sécurité et de vérifier les sauvegardes plutôt que de se contenter de les configurer.

Si l'un de ces points est rédhibitoire, l'offre SaaS est vraiment la bonne réponse pour votre équipe. C'est une position défendable, pas un échec.

Couche 1, coder : Forgejo, Gitea ou GitLab CE

Trois options viables, trois points différents sur la courbe des ressources et de la gouvernance. Pour qui se lance dans l'auto-hébergement en 2026, la recommandation est Forgejo d'abord.

Forgejo est conçu pour une infrastructure modeste et propose pull requests, suivi de tickets, tableaux de projet, wikis, registres de paquets et Forgejo Actions. Ses workflows adoptent un format à la GitHub Actions, mais la compatibilité n'est pas absolue ; testez toutes les actions tierces dont dépend votre pipeline.

Ne choisissez Gitea que si vous dépendez déjà d'une fonction propre à Gitea ou si votre outillage est figé sur une version de Gitea. Le code n'a rien à se reprocher. La comparaison officielle de Forgejo indique que le fork a suivi le transfert, en octobre 2022, des domaines et de la marque de Gitea à une société à but lucratif sans l'accord de la communauté ; l' annonce de licence de Forgejo consigne la licence GPL v3+ pour les versions à partir de la v9.0.

Choisissez GitLab CE si vous voulez un seul produit pour git, CI/CD, registre de conteneurs et suivi des tickets, et que vous pouvez assumer son plancher de ressources. Les exigences actuelles de GitLab fixent 16 Go de RAM et 8 vCPU comme base pour un nœud unique ; les 8 Go visent les environnements contraints en mémoire. Gitea est assez léger pour faire tourner une petite instance privée dans 1 à 2 Go de RAM, et Forgejo est comparable, mais le dimensionnement en production dépend dans les deux cas des dépôts, des runners et des utilisateurs simultanés.

La question du CI mérite d'être soulignée. Gitea Actions vise une compatibilité globale avec GitHub Actions, tandis que Forgejo Actions cherche délibérément la familiarité plutôt que la compatibilité totale. Beaucoup de workflows ne demandent que de petits ajustements, mais les images de runner, les permissions, les contextes, les labels et les actions tierces peuvent se comporter différemment. Testez chaque workflow et chaque action dont dépend votre pipeline avant de migrer.

Une réserve vaut pour les trois options. Ce guide suppose un usage privé et en équipe, avec la surface d'administration derrière un VPN ou une liste d'adresses IP autorisées. Les services git publics affrontent du trafic de bots, des abus et des arbitrages de visibilité qu'un petit déploiement privé ne connaît pas. Pour de l'open source public, faites un miroir sur GitHub pour la visibilité tout en gardant Forgejo comme source de vérité si ce modèle de gouvernance compte pour vous.

Dimensionnez le serveur d'après la charge de travail, pas d'après les noms de forfaits d'un hébergeur. Un service Forgejo ou Gitea isolé pour un usage privé léger peut démarrer autour de 1 à 2 vCPU et 1 à 2 Go de RAM. Une pile réduite sans OpenProject, Plane ni builds locaux peut démarrer autour de 4 vCPU et 8 Go de RAM. Pour la pile complète fondée sur Forgejo décrite ici, partez sur 8 vCPU et 16 Go de RAM, puis validez sous une charge réelle de CI et d'applications. La base officielle de GitLab, 8 vCPU et 16 Go, s'applique à GitLab lui-même : ne la considérez donc pas comme suffisante pour GitLab plus le reste de cette pile. Utilisez du stockage SSD ou NVMe, budgétez séparément dépôts, images de conteneurs, journaux, bases de données et sauvegardes, et gardez 20 à 30 % de capacité libre pour les mises à jour et les pics de charge.

À retenir de cette section : Forgejo est la recommandation par défaut pour la couche code en 2026 ; Gitea reste solide, et GitLab CE n'est le choix intégré que si vous pouvez assumer sa base de 16 Go ou si vous acceptez sciemment une configuration contrainte à 8 Go.

Couche 2, construire et déployer : Coolify (avec réserves), Dokku ou Docker Compose seul

Pour poser les choses honnêtement : Coolify est l'option PaaS recommandée pour cette pile si vous exécutez la dernière version de production, tenez le tableau de bord d'administration hors de l'internet public et suivez les bulletins de sécurité. Au moment de la relecture, GitHub marque Coolify v4.3.0 comme la version la plus récente. Considérez les correctifs et l'isolement du plan d'administration comme des exigences d'exploitation, pas comme un durcissement facultatif.

Astuce de pro : Restreignez le tableau de bord et l'API de Coolify avec un pare-feu, un VPN ou un proxy d'accès de confiance. Les applications déployées peuvent toujours recevoir du trafic public ; l'objectif est de réduire l'exposition du plan de contrôle administratif.

L'alternative pour les développeurs solo est Dokku, un PaaS compact avec des déploiements par git push à la Heroku et la prise en charge des buildpacks. Sa surface est plus réduite que celle de Coolify, et son jeu de fonctions l'est d'autant. Cela en fait un « choix ennuyeux » défendable pour un ou deux développeurs qui n'ont pas besoin d'un tableau de bord.

La troisième option vers laquelle se tournent les opérateurs expérimentés, c'est pas de PaaS du tout, juste Docker Compose. Si votre équipe écrit déjà des fichiers Compose et que vous préférez voir les rouages, c'est une réponse parfaitement raisonnable. Ajoutez Dockge ou Portainer comme couche d'interface pour gérer les piles quand vous voulez un redémarrage en un clic plutôt qu'un docker compose restart. Le compromis est opérationnel : pas d'environnements de prévisualisation, pas d'automatisation TLS intégrée, pas de déploiements sans interruption sans effort. Ces fonctions se gagnent en écrivant des scripts ; avec Coolify elles sont prêtes, avec l'historique de sécurité qui va avec.

LIRE

Meilleures alternatives self-hosted à Heroku et Vercel : Coolify, Dokku et plus

Le guide Cloudzy des meilleurs outils CI/CD approfondit la chaîne de build pour les équipes qui ont besoin d'un runner distinct, ce dont beaucoup de petites équipes se passent une fois Forgejo Actions ou le CI/CD de GitLab en place.

À retenir de cette section : Coolify n'est le PaaS recommandé que sur la version stable actuelle et avec son plan d'administration restreint ; Dokku est le choix prudent en solo ; Docker Compose seul reste une troisième option défendable.

Couche 3, exécuter : Vaultwarden, Uptime Kuma, GlitchTip et la gestion des conteneurs

C'est ici que se loge l'écart de ressources le plus criant de cette pile. Les exigences officielles de Sentry en auto-hébergement indiquent comme minimum 4 cœurs de processeur, 16 Go de RAM, 16 Go de swap et 20 Go de disque libre, avec 32 Go de RAM recommandés. Le guide d'installation de GlitchTip recommande 512 Mo de RAM, exige PostgreSQL et rend Valkey facultatif. Pour une petite équipe sur un seul VPS, GlitchTip est le choix par défaut le plus pratique.

Les quatre outils restants de cette couche se résument vite.

Vaultwarden est un gestionnaire de mots de passe compatible Bitwarden qui prend en charge les applications mobiles et les extensions de navigateur Bitwarden, ainsi que le partage en équipe. Son empreinte réelle dépend des utilisateurs, des pièces jointes et du choix de base de données. Le comparatif Cloudzy des gestionnaires de mots de passe auto-hébergés creuse le compromis quand vous avez besoin de permissions plus structurées, de contrôles d'audit ou d'un autre modèle de sécurité.

Uptime Kuma est le petit outil de supervision et d'alerte : contrôles HTTP, TCP, ping, push, expiration de certificats, et pages de statut en option. Les notifications peuvent passer par la messagerie, l'e-mail ou des webhooks. La consommation varie selon le nombre de sondes et la rétention ; déclencher l'alerte au deuxième échec consécutif est un moyen pratique d'étouffer les faux positifs passagers.

GlitchTip est le traqueur d'erreurs. La plupart des intégrations de SDK Sentry peuvent remonter vers un DSN GlitchTip, mais la parité fonctionnelle n'est pas complète ; testez la supervision des performances, les source maps, les alertes et toute intégration que votre équipe juge critique.

Choisissez Portainer ou Dockge pour l'interface de conteneurs. Portainer couvre un éventail plus large de cas de gestion ; Dockge reste centré sur Docker Compose. Pour une petite pile uniquement en Compose, Dockge tombe plus juste. Ne passez à Portainer que si vous avez besoin de la portée élargie.

Une ergonomie Compose utile pour cette couche : gardez chaque outil dans son propre sous-répertoire avec son propre compose.yml, ne partagez un réseau Docker que là où du trafic entre outils est nécessaire, et placez un seul reverse proxy devant pour la terminaison TLS.

# /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"

Astuce de pro : Une sauvegarde n'est prouvée que lorsque le service peut être restauré et ses données validées. Une fois par mois, restaurez un service représentatif dans un environnement de test isolé, démarrez-le, authentifiez-vous, inspectez les enregistrements et les pièces jointes, et vérifiez que l'application se comporte normalement. Lister les fichiers restaurés prouve seulement que l'archive est lisible, pas que la base de données, les volumes, les permissions et l'état applicatif peuvent être récupérés avec succès.

À retenir de cette section : GlitchTip assure l'essentiel du suivi des erreurs avec un déploiement bien plus léger que Sentry auto-hébergé, mais validez les fonctions et intégrations Sentry que votre équipe utilise réellement.

Couche 4, documenter : Docmost, AFFiNE et le suivi des tickets avec OpenProject ou Plane

L'interface de Notion convient très bien, jusqu'à ce qu'un wiki qui grossit rende la navigation et la recherche pesantes. Pour une petite équipe, la répartition recommandée est Docmost pour la documentation et le wiki, avec OpenProject pour le suivi des tickets. Remplacez OpenProject par Plane si votre équipe veut spécifiquement un modèle visuel à la Linear et se sent à l'aise pour gérer son déploiement auto-hébergé pris en charge.

Docmost est ici le remplaçant auto-hébergé le plus proche de Notion, sans prétendre être Notion. Son éditeur par blocs, sa hiérarchie de pages et ses permissions d'équipe conviennent à un wiki interne classique. Dimensionnez cette couche selon le nombre d'éditeurs simultanés, les pièces jointes et le fait que PostgreSQL et Redis partagent ou non le même hôte. AFFiNE est l'alternative pour les équipes qui préfèrent un modèle de canevas et de tableau blanc aux pages imbriquées. Les deux se défendent ; choisissez-en un.

OpenProject couvre le suivi des tickets pour les équipes à l'aise avec un flux de travail façon Jira : épopées, lots de travaux, sprints et suivi du temps. Plane est l'alternative à la Linear, avec une interface centrée sur les tickets, plus rapide, et une empreinte opérationnelle différente.

Reconnaissons-le honnêtement : la rapidité au clavier de Linear est réellement bonne, et Plane ne reproduit pas toutes les interactions. Si le flux de travail de votre équipe repose sur la mémoire musculaire du menu de commandes de Linear, la friction de migration est bien réelle. Ce n'est pas forcément rédhibitoire, mais c'est un coût véritable.

À retenir de cette section : Docmost tient le rôle de la documentation interne, tandis qu'OpenProject ou Plane assure le suivi des tickets ; l'écart d'ergonomie clavier avec Linear est le seul endroit où cette couche vous demande un compromis.

Ce que coûte cette pile et sur quoi elle tourne

Le point de départ pratique pour la pile complète fondée sur Forgejo sur une seule machine se situe autour de 8 vCPU et 16 Go de RAM. Considérez 2 vCPU et 4 Go de RAM comme une taille de laboratoire pour quelques services légers, et 4 vCPU et 8 Go de RAM comme un pilote réduit qui laisse de côté OpenProject, Plane et les builds locaux. Les besoins réels dépendent des utilisateurs simultanés, de l'activité de CI, de la croissance des bases de données, des pièces jointes, du stockage d'images, des journaux et de la rétention : validez donc la pile sous charge réelle et gardez 20 à 30 % de capacité libre. Le palier de départ à 16 Go peut accueillir les services suivants pour une équipe de 2 à 3 développeurs peu sollicitée, sous réserve de tests de charge :

• Forgejo
• Coolify
• Vaultwarden
• Uptime Kuma
• GlitchTip
• Docmost
• OpenProject
• Dockge

Un serveur de 4 Go ne convient qu'à quelques services légers. Un serveur de 8 Go se traite plutôt comme un pilote réduit sans OpenProject, Plane ni builds locaux. Démarrez la pile complète fondée sur Forgejo à 16 Go, et ajoutez de la capacité si vous faites tourner GitLab, des builds simultanés, Plane, de longues durées de rétention ou des charges de base de données plus lourdes. Le lot SaaS de la même équipe comprend :

• GitHub Team
• Vercel Pro
• Sentry
• Linear
• Notion
• 1Password

En reprenant les tarifs de base publiés sur chaque page de prix (y compris les tarifs en facturation annuelle le cas échéant). Les cinq produits chiffrés totalisent environ 158 $ par mois pour trois personnes : GitHub Team à 4 $ par utilisateur les 12 premiers mois, trois sièges développeur Vercel Pro à 20 $ chacun, Sentry Team à partir de 26 $, Linear Basic à 10 $ par utilisateur, et Notion Plus à 10 $ par utilisateur. Les frais à l'usage, les taxes, les options et 1Password viennent en plus. L'infrastructure peut rester nettement moins chère, mais la comparaison n'a pas de sens sans le temps de l'exploitant.

Quand passer à la taille au-dessus : la base de GitLab sur un nœud unique est de 8 vCPU et 16 Go de RAM. Plusieurs builds simultanés peuvent exiger de la capacité supplémentaire, même sans GitLab. Sentry auto-hébergé démarre lui aussi à 16 Go de RAM plus 16 Go de swap et en recommande 32 : c'est pourquoi ce guide recommande GlitchTip pour la pile monobloc.

Le coût non chiffré, c'est le temps d'exploitation. En estimation de planification, prévoyez 1 à 2 heures par mois pour les mises à jour et la vérification des sauvegardes, plus un survol hebdomadaire des bulletins de sécurité des projets que vous faites tourner. Le chiffre réel dépend du volume de changements, de la réponse aux incidents et de votre degré d'automatisation. Il n'est pas nul, et il a sa place dans le modèle de coûts.

La méthode de déploiement change le confort, pas les exigences d'exploitation. Que vous partiez d'un fichier Compose officiel ou d'un modèle de place de marché, figez les versions d'images, fixez des limites de processeur et de mémoire, gardez les données de service dans des volumes nommés, et testez à la fois les sauvegardes et les restaurations. Réunir toute la pile sur un seul hôte crée aussi un domaine de panne commun : isolez donc les services critiques quand une interruption ou une fuite d'identifiants aurait un fort impact.

Si vous voulez déployer cette pile, comparez nos offres de Cloud VPS selon le processeur, la RAM, le stockage SSD ou NVMe, le volume de transfert et la région, puis appliquez le cadre de dimensionnement ci-dessus. Pour aller plus vite, parcourez notre catalogue d'applications en un clic, mais figez tout de même les versions, fixez des limites de ressources et vérifiez les sauvegardes avant la production.

À retenir de cette section : Prenez 4 Go pour un petit laboratoire, 8 Go pour un pilote réduit, et environ 8 vCPU avec 16 Go de RAM comme point de départ pratique de la pile complète fondée sur Forgejo. Ajoutez de la capacité pour GitLab, les builds simultanés, les outils de gestion de projet plus lourds et les bases de données qui grossissent.

Là où auto-héberger cette pile échoue vraiment

Quatre modes de défaillance, nommés sans détour, parce que le reste de ce guide a plaidé pour l'approche.

Mode de défaillance 1 : l'effet de réseau de GitHub pour les projets open source publics. Le git auto-hébergé est le bon choix pour du code privé. C'est le mauvais choix pour des projets dont toute la valeur tient à ce que des contributeurs extérieurs vous trouvent. GitHub est le premier endroit où les développeurs regardent. Pull requests, forks, étoiles, le signal de confiance implicite d'être sur github.com, les intégrations d'outils tiers, tout cela. Si votre projet est en open source public, le schéma honnête consiste à faire un miroir sur GitHub pour la visibilité tout en gardant la source de vérité sur Forgejo. N'attendez pas d'une instance auto-hébergée qu'elle remplace la découvrabilité de GitHub pour du travail public. Elle ne le fera pas.

Mode de défaillance 2 : le trafic de bots et de moissonneurs sur les instances Git publiques. Les services Forgejo et Gitea exposés au public ont besoin de contrôles anti-abus, de limitation de débit, de supervision et d'assez de capacité pour un trafic imprévisible. Ce guide suppose un usage privé et en équipe, avec la surface d'administration derrière un VPN ou une liste d'adresses IP autorisées. Une forge réellement publique relève d'un autre modèle de menace et de capacité.

Mode de défaillance 3 : la charge de maintenance. « C'est vous, le service informatique » est le cliché, et il est en grande partie vrai. Les mises à jour cassent des choses. Les fichiers Compose dérivent. Les certificats expirent. Les sauvegardes échouent en silence, de la façon la plus indigne qui soit. Les bulletins de sécurité 2026 de Coolify rappellent utilement que la cadence de correctifs compte. Si vous ne pouvez pas vous engager sur une fenêtre de maintenance avant de vous lancer, l'offre SaaS est honnêtement la bonne réponse.

Mode de défaillance 4 : la perte d'intégrations. Les actions GitHub tierces, les déploiements de prévisualisation Vercel liés aux pull requests GitHub, les intégrations d'alerte hébergées de Sentry avec PagerDuty et Linear, le vaste catalogue d'intégrations de Notion. La plupart ont des équivalents auto-hébergés (Forgejo Actions, déploiements par webhook de Coolify, notifications GlitchTip, n8n comme colle entre workflows), mais les substitutions ne sont pas toujours au un pour un. Prototypez le flux de travail qui compte le plus avant d'engager l'équipe dans la migration. L'intégration que vous tenez pour acquise est celle qui a le plus de chances de vous surprendre.

À retenir de cette section : Cette pile fonctionne pour du code privé, de petites équipes et des exploitants volontaires ; elle ne fonctionne pas pour la visibilité de l'open source public, les équipes qui ne veulent rien toucher, ni les attentes de zéro maintenance.

La pile de l'exploitant

Quatre couches, quatre recommandations, nommées honnêtement. Coder : Forgejo. Construire et déployer : Coolify avec le plan d'administration restreint, ou Dokku, ou Compose. Exécuter : Vaultwarden, Uptime Kuma, GlitchTip, Portainer ou Dockge. Documenter : Docmost et OpenProject (ou Plane). Démarrez un pilote réduit à 8 Go et la pile complète fondée sur Forgejo à 16 Go. Ajoutez de la capacité pour GitLab, les builds simultanés, les bases de données plus lourdes ou une charge applicative soutenue.

Si vous migrez, commencez par Uptime Kuma et un service interne non critique. Ils offrent un moyen à moindre risque d'apprendre la cadence d'exploitation (mises à jour, supervision, vérification des sauvegardes et renouvellement des certificats) avant de déplacer un flux de travail d'équipe ou un coffre d'identifiants. Ne faites pas de Vaultwarden le premier déploiement d'essai : ne le déplacez qu'une fois en place des sauvegardes chiffrées hors de l'hôte, un test de restauration réussi, une administration restreinte et l'authentification multifacteur. Quand cette cadence est fiable, passez à Forgejo, puis à Coolify, puis au reste.

Pour les équipes qui choisissent spécifiquement GitLab CE, décidez si son CI/CD natif remplace un runner distinct ou si votre charge de travail exige encore une capacité de build dédiée.

Foire aux questions

Quelle est la meilleure alternative auto-hébergée à Gitea en 2026 ?

Forgejo est le choix recommandé pour qui se lance dans l'auto-hébergement en 2026. Le transfert, en octobre 2022, de la marque et du domaine de Gitea à une société à but lucratif sans accord préalable de la communauté a provoqué le fork Forgejo fin 2022. À partir de la v9.0, les versions de Forgejo sont sous GPL v3+ ; les versions correctives antérieures v8.0 et v7.0 sont restées sous MIT. Au quotidien, la parité fonctionnelle est proche.

Peut-on faire tourner Coolify en production en toute sécurité en 2026 ?

Oui, mais uniquement avec une maintenance active et une défense en profondeur. Faites tourner la dernière version stable revue, surveillez les nouveaux bulletins, restreignez les permissions de l'équipe et gardez le tableau de bord et l'API derrière un pare-feu, un VPN ou une couche d'accès de confiance. Ne considérez pas beta.451, beta.474 ni aucun autre niveau de correctif historique comme un seuil de sécurité permanent.

De combien de RAM une pile de développement auto-hébergée complète a-t-elle réellement besoin ?

Pour une équipe de 2 à 3 développeurs, considérez 4 Go comme une taille de laboratoire pour quelques services légers et 8 Go comme un pilote réduit sans OpenProject, Plane ni builds locaux. Environ 8 vCPU et 16 Go de RAM constituent le point de départ pratique de la pile complète fondée sur Forgejo. La base 8 vCPU / 16 Go de GitLab s'applique à GitLab lui-même, tandis que Sentry auto-hébergé exige 16 Go de RAM plus 16 Go de swap et en recommande 32. Validez la configuration finale dans des conditions de charge réelles.

Pourquoi GlitchTip plutôt que Sentry auto-hébergé ?

L'écart de ressources et d'exploitation. Sentry auto-hébergé exige au moins 16 Go de RAM plus 16 Go de swap et constitue un déploiement volumineux à plusieurs services. GlitchTip recommande 512 Mo pour son service tout-en-un, exige PostgreSQL et rend Valkey facultatif. Il accepte le trafic des SDK Sentry, mais la parité fonctionnelle n'est pas complète : testez donc les fonctions et intégrations dont vous dépendez.

Combien coûte réellement cette pile face aux équivalents SaaS ?

Considérez 4 Go comme une taille de laboratoire pour quelques services légers et 8 Go comme un pilote réduit sans OpenProject, Plane ni builds locaux. Environ 8 vCPU et 16 Go de RAM constituent le point de départ pratique de la pile complète fondée sur Forgejo. Aux prix de base publiés, GitHub Team, Vercel Pro, Sentry Team, Linear Basic et Notion Plus totalisent environ 158 $ par mois pour trois personnes, avant 1Password, les frais à l'usage, les taxes et les options. L'auto-hébergement peut coûter nettement moins cher, mais le temps de l'exploitant et l'infrastructure de sauvegarde sont des coûts bien réels.