Auto-hébergement
Exécutez Mintlify dans votre propre cloud ou en on-premises, sur AWS ou toute plateforme Kubernetes comme Azure, Google Cloud, Oracle Cloud ou OpenShift.
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.
| Plateforme | Méthode |
|---|---|
| Amazon Web Services | Application AWS Cloud Development Kit (CDK) |
| Microsoft Azure | Helm chart sur Azure Kubernetes Service (AKS) |
| Google Cloud | Helm chart sur Google Kubernetes Engine (GKE) |
| Oracle Cloud | Helm chart sur Oracle Container Engine for Kubernetes (OKE) |
| Red Hat OpenShift | Helm chart |
| Tout Kubernetes | Helm chart |
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.
| Domaine | Hébergé dans le cloud | Auto-hébergé |
|---|---|---|
| Délai de mise en service | Le jour même | Engagement cadré, généralement plusieurs semaines |
| Infrastructure | Mintlify exploite tout | Vous exploitez le cluster, le réseau et les magasins de données. Mintlify livre des versions numérotées avec des guides de mise à niveau et prend en charge la couche applicative |
| Mises à jour de la plateforme | Continues et automatiques | Versions numérotées que vous examinez et déployez selon votre propre calendrier |
| Frontière des données | Traitées dans le cloud de Mintlify | Le contenu, les builds, les analyses et les logs restent à l’intérieur de votre réseau, sans sortie vers des tiers |
| Fonctionnalités d’IA | Activées par défaut | Livrées désactivées jusqu’à ce que votre équipe de sécurité ou de gouvernance de l’IA les approuve. Peuvent s’exécuter sur votre propre endpoint de modèle, votre propre clé API ou le cloud Mintlify |
| Intégrations | Catalogue complet | Les intégrations qui dépendent des services cloud de Mintlify ne sont pas disponibles |
| Supervision | Gérée par Mintlify | Vous branchez votre propre stack d’observabilité |
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é.
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é.
| Fonctionnalité | Disponibilité | Notes |
|---|---|---|
| Site de documentation | Rendu complet, composants et personnalisation du thème | |
| Éditeur web | Rédaction depuis le navigateur | |
| Workflow adossé à Git | GitHub, GitHub Enterprise Server, GitLab y compris self-managed, Bitbucket, ou une API proxy détenue en interne | |
| Recherche | S’exécute à l’intérieur de votre déploiement. L’index est reconstruit à la publication | |
| Contenu authentifié | Contrôle d’accès via votre fournisseur d’identité | |
| SSO du dashboard | OIDC ou SAML | |
| Analyses | Collectées et stockées à l’intérieur de votre réseau | |
| Widgets d’analyse et de support tiers | Configurés avec vos propres clés, servis depuis le site de documentation | |
| Export statique | Bundles autonomes pour une diffusion en air-gapped | |
| Versions et rollback | Chaque version fige les versions d’image. Revenez en arrière en redéployant la version précédente | |
| Assistant et agent d’IA | Optionnel | Livrés désactivés. S’exécutent sur votre propre endpoint de modèle, votre propre clé API ou le cloud Mintlify |
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.
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.
| Ressource | Rôle | Requis |
|---|---|---|
| Équilibreur de charge ou ingress | Terminaison TLS et routage | |
| Site de documentation | Sert la documentation rendue | |
| Dashboard et API | Administration, authentification et orchestration des builds | |
| Workers de build | Compilent et publient les sites de documentation | |
| MongoDB | Magasin de contenu | |
| PostgreSQL | Métadonnées de déploiement et d’utilisateurs | |
| Redis | File d’attente de build et cache | |
| Stockage d’objets | Bundles de sites compilés et exports statiques | |
| Recherche et indexation | Recherche dans la documentation. L’index est reconstruit à la publication | |
| Fournisseur d’identité | SSO OIDC ou SAML pour le dashboard et le contenu authentifié | |
| Services d’assistant d’IA | Fonctionnalités d’assistant et d’agent | Optionnel |
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.
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.
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
| Composant | Exigence | Notes |
|---|---|---|
| Calcul | Cluster Amazon ECS | Exécute les services Mintlify |
| Magasin de contenu | Amazon DocumentDB | Compatible MongoDB |
| Magasin de métadonnées | Amazon RDS for PostgreSQL | Métadonnées de déploiement et d’utilisateurs |
| Cache et file d’attente | Amazon ElastiCache for Redis | File d’attente de build et cache |
| Stockage d’objets | Amazon S3 | Bundles de sites compilés et exports statiques |
| CDN | Amazon CloudFront | Sert le site de documentation en périphérie |
| Réseau | VPC avec sous-réseaux publics et privés, Application Load Balancer | Isole les charges de travail |
| TLS et DNS | AWS Certificate Manager, Amazon Route 53 | HTTPS et routage pour votre domaine |
| Secrets | AWS Secrets Manager | Identifiants de base de données et secrets de signature |
| Identité | Fournisseur OIDC ou SAML | SSO du dashboard |
Configuration
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.
Configure and deploy
Définissez votre domaine, votre certificat et votre réseau dans le contexte CDK, examinez le change set et déployez.
cdk diff
cdk deploy --allConnect Git and SSO
Accordez au déploiement l’accès à vos dépôts de documentation et connectez votre fournisseur d’identité.
Cut over
Vérifiez les builds et la recherche sur votre domaine de staging, puis pointez votre DNS de production vers le déploiement.
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.
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.
# examinez le change set pour la nouvelle version, puis déployez-la
cdk diff
cdk deploy --allLes 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.
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.
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.