Skip to main content
L’auto-hébergement nécessite un plan Enterprise. Contactez votre équipe de compte pour cadrer un déploiement.
L’auto-hébergement exécute Mintlify dans votre propre compte cloud ou data center, afin que votre contenu, votre pipeline de build, vos analyses et vos logs restent à l’intérieur des limites de votre réseau. Il est conçu pour les équipes ayant des exigences de résidence des données, de conformité ou d’air-gap auxquelles un déploiement hébergé dans le cloud ne peut pas répondre. Chaque déploiement auto-hébergé est un engagement cadré avec votre équipe de compte, et non une installation en libre-service. Cette page décrit ce que vous provisionnez, comment le déploiement fonctionne et les compromis par rapport à l’hébergement cloud, afin que vous puissiez évaluer l’auto-hébergement avant de vous y engager.

​
Plateformes prises en charge

​
Comparaison de l’auto-hébergement et de l’hébergement cloud

La rédaction fonctionne de la même manière dans les deux modèles d’hébergement. Votre équipe entretient le contenu avec l’éditeur ou son workflow Git, et chaque modification suit le processus de revue de votre dépôt. Ce qui change, c’est qui exploite la plateforme et où résident les données. Les déploiements auto-hébergés commencent en général de manière restreinte et s’étendent. Un cheminement courant consiste à démarrer avec de la documentation publique, puis à ajouter du contenu authentifié, l’éditeur web et les fonctionnalités d’IA à mesure que vous validez les revues de sécurité.

​
Fonctionnalités

Tout ce qui est essentiel à la rédaction, au build et à la diffusion de la documentation est inclus dans un déploiement auto-hébergé. Seules quelques surfaces plus restreintes qui dépendent de services exploités par Mintlify sont réservées au cloud : l’application Slack, les connecteurs tiers pour les automatisations de l’agent et les intégrations de génération de SDK.

​
Architecture

Un déploiement auto-hébergé est un ensemble de services avec des dépendances claires. Provisionnez d’abord les magasins de données, puis les services qui en dépendent, puis la périphérie. La source de votre documentation peut être GitHub, GitHub Enterprise Server, GitLab (y compris self-managed) ou Bitbucket. Si votre organisation ne peut pas fournir d’identifiants de dépôt à un service tiers, vous pouvez à la place placer votre hébergement Git derrière une API proxy détenue en interne, et les environnements totalement air-gapped utilisent l’export statique sans aucune connexion Git.

​
Dimensionnement

Comme point de départ, un déploiement de production s’exécute sur environ 45 à 60 vCPU, 160 à 220 Go de mémoire et environ 1 To de stockage SSD réparti entre les services, les environnements hors production tournant à environ la moitié. Votre équipe de compte dimensionne le déploiement avec vous en fonction du nombre de pages, du trafic et des fonctionnalités que vous activez.

​
Mettre en place votre plateforme

Les déploiements AWS utilisent une application AWS CDK qui provisionne et met à jour l’ensemble de la stack dans votre compte. L’application CDK fige les images de conteneur sur des versions spécifiques, de sorte que chaque déploiement est reproductible et vérifiable.

​
Ce que vous fournissez

​
Configuration

1

Scope the deployment

Votre équipe de compte examine votre topologie réseau, votre hébergement Git, votre fournisseur d’identité et vos exigences de conformité, puis livre l’application CDK et l’accès aux images de conteneur numérotées.
2

Configure and deploy

Définissez votre domaine, votre certificat et votre réseau dans le contexte CDK, examinez le change set et déployez.
3

Connect Git and SSO

Accordez au déploiement l’accès à vos dépôts de documentation et connectez votre fournisseur d’identité.
4

Cut over

Vérifiez les builds et la recherche sur votre domaine de staging, puis pointez votre DNS de production vers le déploiement.

​
Mises à jour

Les mises à jour de la plateforme et les mises à jour du contenu évoluent indépendamment. Vous contrôlez le moment où la plateforme change, et votre documentation reste à jour d’elle-même.

​
Mises à jour de la plateforme

Mintlify livre des versions numérotées avec des guides de mise à niveau et des notes de version, via votre équipe de compte. Chaque version fige des versions d’image spécifiques, ce qui vous permet de tester une release dans un environnement hors production avant de la déployer et de revenir à la version précédente si besoin.
Les mises à jour se déploient sans interruption de service. De nouvelles tâches ou de nouveaux pods démarrent, passent les health checks et remplacent les anciens.

​
Mises à jour du contenu

Le contenu passe par votre source Git, pas par les releases de la plateforme. Lorsque vous poussez sur votre dépôt de documentation, les workers de build reconstruisent le site et le publient automatiquement dans le stockage d’objets. Les changements de contenu ne nécessitent jamais un déploiement de plateforme.

​
Déploiements air-gapped

Les environnements sans chemin de webhook Git servent la documentation sous forme de bundles d’export statique. Des builds autonomes de votre site sont publiés dans le stockage d’objets et servis via votre CDN. Régénérez le bundle quand le contenu change, ou automatisez la boucle avec une GitHub Action. Les fonctionnalités d’IA qui nécessitent un accès réseau sortant sont désactivées dans les déploiements air-gapped.

​
Étapes suivantes

Parlez à votre équipe de compte

Cadrez un déploiement auto-hébergé sur votre plateforme et planifiez votre lancement.

Export statique

Générez des bundles autonomes de votre documentation pour une diffusion en air-gapped.