Self-host

Run Mintlify inside your own cloud or on-premises environment, on AWS or any Kubernetes platform including Azure, Google Cloud, Oracle Cloud, and OpenShift.

Self-hosting runs Mintlify inside your own cloud account or data center, so your content, build pipeline, analytics, and logs stay within your network boundary. It's designed for teams with data-residency, compliance, or air-gap requirements that a cloud-hosted deployment can't meet.

Every self-hosted deployment is a scoped engagement with your account team, not a self-serve install. This page describes what you provision, how the deployment runs, and the tradeoffs against cloud hosting so you can evaluate self-hosting before committing to it.

Authoring works the same way in both hosting models. Your team maintains content with the editor or their Git workflow, and every change flows through your repository's review process. What changes is who operates the platform and where data resides.

Self-hosted deployments usually start narrow and expand. A common path is to start with public documentation, then add authenticated content, the web editor, and AI features as you complete security reviews.

Everything core to authoring, building, and serving documentation ships in a self-hosted deployment.

Only smaller surfaces that depend on Mintlify-operated services are cloud-only: the Slack app, third-party connectors for agent automations, and SDK generation integrations.

A self-hosted deployment is a set of services with clear dependencies. Provision the data stores first, then the services that depend on them, then the edge.

flowchart TD
  U[Users] --> CDN[CDN and WAF]
  CDN --> ING[Load balancer or ingress]
  ING --> WEB[Docs site]
  ING --> API[Dashboard and API]
  API --> BUILD[Build workers]
  BUILD --> GIT[Git source]
  WEB --> OBJ[(Object storage)]
  BUILD --> OBJ
  API --> MONGO[(MongoDB)]
  API --> PG[(PostgreSQL)]
  API --> REDIS[(Redis)]
  API --> SEARCH[Search and indexing]
  API --> IDP[Identity provider]
  API -. optional .-> AI[AI assistant services]

Your documentation source can be GitHub, GitHub Enterprise Server, GitLab (including self-managed), or Bitbucket.

If your organization can't grant repository credentials to a third-party service, front your Git hosting with an internally owned proxy API instead. Fully air-gapped environments use static export with no Git connection at all.

As a starting point, a production deployment runs on roughly 45 to 60 vCPU, 160 to 220 GB of memory, and about 1 TB of solid-state storage across services. Non-production environments run at about half that. Your account team sizes the deployment with you based on page count, traffic, and which features you enable.

Platform updates and content updates move independently. You control when the platform changes, and your documentation stays current on its own.

Mintlify ships versioned releases with upgrade guides and release notes from your account team. Each release pins specific image versions, so you can test a release in a non-production environment before deploying it and roll back to the previous version if needed.

# review the change set for the new release, then roll it out
cdk diff
cdk deploy --all

# upgrade to a delivered release, or roll back
helm upgrade mintlify ./mintlify-enterprise \
  --namespace mintlify -f values.yaml
helm rollback mintlify

Updates roll out with no downtime. New tasks or pods start, pass health checks, and replace the old ones.

Content flows through your Git source, not through platform releases. When you push to your documentation repository, the build workers rebuild the site and publish it to object storage automatically. Content changes never require a platform deploy.

Environments with no Git webhook path serve documentation as static export bundles. Self-contained builds of your site are published to object storage and served through your CDN. Regenerate the bundle when content changes, or automate the loop with a GitHub Action. AI features that require outbound network access are disabled in air-gapped deployments.

• Custom developer portals
• Use the assistant
• Self-hosted GitLab OAuth