Aller au contenu
EuroVPSEuroVPS

Ce que nous faisons · Plateformes: Gestion de sources infogérée sur GitLab

Une instance GitLab privée pour votre code, votre configuration et vos runbooks, sur des réseaux privés dans nos datacenters, maintenue et sauvegardée.
Fibre peignée dans un switch Cisco Nexus

Votre code source, la configuration de votre infrastructure et vos runbooks sont le texte le plus précieux que possède votre entreprise. Nous exploitons pour vous une instance GitLab privée, dans un espace d'adressage privé dans nos propres datacenters, pour que l'historique de tout ce que vous construisez vive sur un serveur que vous contrôlez et ne soit jamais à un token fuité de l'internet.

De quoi il s'agit

  • h2: De quoi il s'agit

Un GitLab dédié et auto-hébergé : dépôts, merge requests, tickets et éléments de travail, wikis, registre de conteneurs et pipelines CI, pour votre organisation seule. Il peut se trouver entièrement sur un réseau privé joignable uniquement par votre VPN, ou faire face à l'internet derrière une politique de firewall que vous décidez.

Nous l'exploitons : installation, durcissement, backups, supervision, avis de sécurité et mises à niveau. Vos développeurs ont GitLab. Vous cessez de vous demander où vit réellement votre code.

Comment nous le construisons

  • h2: Comment nous le construisons

GitLab tourne en conteneurs Podman sous systemd sur Oracle Linux, avec SELinux en mode enforcing. Par défaut, il ne vit que sur des réseaux privés. Les développeurs l'atteignent par un VPN ou depuis vos propres bureaux ; l'internet public ne le voit pas du tout.

Les backups sont pris depuis le côté backup, qui tire depuis la plateforme. La plateforme elle-même n'a aucune route vers l'infrastructure de backup, de sorte qu'un serveur compromis ne peut ni atteindre ni endommager ses propres backups.

Quand GitLab publie un correctif, nous le vérifions contre votre installation exacte et nous écrivons l'exposition réelle : la fonctionnalité concernée est-elle activée, le chemin vulnérable est-il atteignable depuis là où se trouve un attaquant, quel est le risque résiduel à l'intérieur. Cette évaluation tranche entre une fenêtre d'urgence ce soir et une fenêtre planifiée cette semaine, et vous recevez le raisonnement, pas seulement un score de gravité.

La migration entrante fait partie du service : les dépôts avec tout leur historique, les tickets, les merge requests et les utilisateurs depuis un autre GitLab, ou l'historique git brut depuis d'autres plateformes.

Ce dont il vous protège

  • h2: Ce dont il vous protège

  • Du code et de la configuration qui n'existent que sur le portable d'un seul ingénieur.

  • Des secrets qui fuient vers un service public d'hébergement de code par un seul push imprudent.
  • Une plateforme SaaS publique qui change ses tarifs, ses conditions ou sa disponibilité sous votre pipeline de build.
  • Un score de gravité en gros titre qui force une mise à niveau dans la panique alors que le chemin vulnérable n'a jamais été atteignable, ou l'inverse : une exposition réelle laissée ouverte parce que personne n'a regardé.
  • Une instance sauvegardée en poussant vers un endroit qu'un attaquant peut aussi atteindre.

En pratique

  • h2: En pratique

Nous pouvons aussi poser des garde-fous autour des habitudes de vos équipes : des commits et des push planifiés pour que le travail ne reste pas sur un portable, et un contrôle pre-push qui refuse d'envoyer des identifiants ou des données internes vers tout remote en dehors d'une allow list que vous approuvez.

Pourquoi EuroVPS

  • h2: Pourquoi EuroVPS

  • Privé par défaut : votre GitLab peut vivre sur des réseaux que l'internet ne voit jamais.

  • Des avis de sécurité évalués contre votre installation réelle, par écrit, le jour même.
  • Des backups tirés depuis le côté sécurisé ; la production ne pousse jamais vers le backup.
  • Hébergé dans nos propres datacenters à Athènes, Amsterdam ou Toronto, sur du stockage all-flash d'entreprise.
  • Des ingénieurs qui dépendent de GitLab pour leur propre travail chaque jour.

Questions fréquentes

  • h2: Questions fréquentes
  1. Les runners CI peuvent-ils tourner sur nos propres serveurs ? Oui. Les runners peuvent se trouver sur des serveurs dédiés ou des machines de private cloud que nous exploitons pour vous, à côté de l'instance, sur le même réseau privé.
  2. Pouvez-vous nous faire migrer depuis un service public d'hébergement de code ? Oui. Nous déplaçons les dépôts avec tout leur historique, et depuis un autre GitLab nous déplaçons aussi les tickets, les merge requests et les utilisateurs.
  3. Est-il joignable depuis l'internet ? Seulement si vous le voulez. Par défaut, accès par réseau privé et VPN uniquement.
  4. À quelle vitesse les correctifs de sécurité sont-ils appliqués ? Chaque avis est évalué le jour même. Une exposition réelle obtient une fenêtre d'urgence ; tout le reste va dans une fenêtre planifiée, et vous voyez l'évaluation dans les deux cas.
  5. Pouvons-nous continuer à utiliser nos outils existants ? Oui. C'est un GitLab standard : la même interface web, les mêmes API, les mêmes clients git et les mêmes intégrations que vos équipes utilisent aujourd'hui.
  • closing: Votre code, c'est votre entreprise. Gardez-le sur un serveur que vous contrôlez. Parler à un ingénieur.

Votre prochain partenaire d'infrastructure

Examinons votre environnement.

Dites-nous ce que vous faites tourner aujourd'hui et ce qui doit s'améliorer. Un ingénieur examinera votre demande et vous aidera à planifier la suite.

+357 222 32280
Un ingénieur EuroVPS transportant un nœud serveur dans la salle du datacenter
Une conversation avec les personnes qui prendront soin de votre infrastructure.

Commençons par votre environnement.

Un peu de contexte nous aide à démarrer la bonne conversation.

Nous utiliserons vos coordonnées pour répondre à votre demande. Politique de confidentialité