Aller au contenu principal

Configurer le serveur MCP distant GitGuardian en Self-Hosted

Bêta

Le serveur MCP GitGuardian est actuellement en bêta. Les fonctionnalités et le comportement peuvent évoluer au fur et à mesure de nos itérations basées sur les retours des utilisateurs.

Le chart Helm GitGuardian Self-Hosted fournit le serveur MCP distant en tant que composant optionnel. Il s'exécute dans votre propre cluster, à côté de votre instance, afin qu'aucun trafic ni aucun secret ne quitte jamais votre réseau.

Prérequis :

  • GitGuardian Self-Hosted 2026.7.0 ou version ultérieure.
  • Avec le contrôleur d'ingress aws_alb, AWS Load Balancer Controller 2.14 ou version ultérieure (pour une installation basée sur Helm).

Activer le serveur MCP

Ajoutez ce qui suit à votre fichier de values Helm :

mcpServer:
enabled: true

Exécutez ensuite helm upgrade avec la version actuellement installée, afin d'éviter une mise à niveau non souhaitée de votre instance. Utilisez helm ls pour trouver le nom de la release et cette version :

helm upgrade <release-name> -n <namespace> oci://registry.replicated.com/gitguardian/gitguardian --version <installed-version> -f local-values.yaml

Une fois le pod en cours d'exécution, le serveur MCP est servi sous le chemin /mcp-server de l'hôte de votre application, sur le même ingress et le même certificat TLS que votre dashboard. Le proxy OAuth est activé par défaut, de sorte que vos développeurs se connectent sur votre propre domaine et qu'aucun token n'a besoin d'être distribué.

Connecter un client MCP

Pointez les clients vers le point de terminaison /mcp du serveur MCP. Pour Cursor, modifiez ~/.cursor/mcp.json :

{
"mcpServers": {
"GitGuardian": {
"type": "http",
"url": "https://dashboard.gitguardian.mycorp.local/mcp-server/mcp"
}
}
}

Remplacez l'hôte par l'URL de votre propre instance. Claude Desktop, Windsurf et Zed acceptent le même bloc type: http dans leur propre fichier de configuration. Consultez Installation pour connaître l'emplacement des fichiers.

Le client ouvre un onglet de navigateur vers votre dashboard lors de sa première connexion. Les outils qu'il expose ensuite dépendent des permissions du compte qui se connecte, de sorte qu'un développeur et un manager n'obtiennent pas le même ensemble. Consultez la référence des outils.

Ajuster le déploiement

Les clés les plus utiles, en plus de mcpServer.enabled :

CléObjectifValeur par défaut
mcpServer.replicasNombre fixe de réplicas1
mcpServer.autoscaling.hpa.enabledMise à l'échelle avec le HPA de Kubernetesfalse
mcpServer.autoscaling.metrics.targetLatencyLatence cible en millisecondes pilotant l'autoscaling1000
mcpServer.resourcesRequêtes et limites de CPU et de mémoire250m / 1Gi demandés
mcpServer.ingress.enabledExposer le serveur via l'ingress de l'applicationtrue
mcpServer.mcpOAuthProxyEnabledPermettre aux clients d'exécuter OAuth contre votre dashboardtrue
mcpServer.extraEnvVariables d'environnement supplémentaires transmises au serveur[]

La liste complète se trouve dans la référence des values Helm. Pour les variables d'environnement que vous pouvez injecter via mcpServer.extraEnv, consultez la référence de configuration du dépôt du serveur MCP.

Dans un environnement airgapped, mettez en miroir ghcr.io/gitguardian/mcp-server vers votre registre privé avec les autres images GitGuardian. Consultez Installation airgap.

Dépanner

Le client ne parvient pas à joindre le serveur. Vérifiez que mcpServer.ingress.enabled est à true et que votre contrôleur d'ingress route le chemin /mcp-server. Sur AWS ALB, confirmez que le Load Balancer Controller est en version 2.14 ou ultérieure.

Le flux OAuth échoue ou redirige vers le mauvais hôte. Le serveur MCP dérive son URL publique de l'hôte de votre application. Assurez-vous que les clients utilisent le même hôte que votre dashboard, et non une adresse de service interne.

Certains outils sont manquants. Les outils exposés suivent les permissions du compte qui s'est connecté. Vérifiez le rôle et les périmètres d'équipe de ce membre.

Et ensuite