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 requires an Enterprise plan. Reach out to your account team to scope a deployment.

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.

Platform support

Platform	Method
Amazon Web Services	AWS Cloud Development Kit (CDK) app
Microsoft Azure	Helm chart on Azure Kubernetes Service (AKS)
Google Cloud	Helm chart on Google Kubernetes Engine (GKE)
Oracle Cloud	Helm chart on Oracle Container Engine for Kubernetes (OKE)
Red Hat OpenShift	Helm chart
Any Kubernetes	Helm chart

How self-hosting compares to cloud hosting

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.

Area	Cloud-hosted	Self-hosted
Time to launch	Same day	Scoped engagement, typically weeks
Infrastructure	Mintlify operates everything	You operate the cluster, network, and data stores. Mintlify ships versioned releases with upgrade guides and supports the application tier
Platform updates	Continuous, automatic	Versioned releases that you review and deploy on your own schedule
Data boundary	Processed in Mintlify’s cloud	Content, builds, analytics, and logs stay inside your network with no third-party egress
AI features	On by default	Ship disabled until your security or AI governance team approves them. Can run against your own model endpoint, your own API key, or Mintlify cloud
Integrations	Full catalog	Integrations that depend on Mintlify cloud services are unavailable
Monitoring	Managed by Mintlify	You connect your own observability stack

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.

Features

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

Feature	Availability	Notes
Documentation site		Full rendering, components, and theming
Web editor		Browser-based authoring
Git-backed workflow		GitHub, GitHub Enterprise Server, GitLab including self-managed, Bitbucket, or an internally owned proxy API
Search		Runs inside your deployment. The index rebuilds on publish
Authenticated content		Access control through your identity provider
Dashboard SSO		OIDC or SAML
Analytics		Collected and stored inside your network
Third-party analytics and support widgets		Configured with your own keys, served from the docs site
Static export		Self-contained bundles for air-gapped serving
Versioned releases and rollback		Each release pins image versions. Roll back by redeploying the previous version
AI assistant and agent	Optional	Ships disabled. Runs against your own model endpoint, your own API key, or Mintlify cloud

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.

Architecture

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.

Resource	Purpose	Required
Load balancer or ingress	TLS termination and routing
Docs site	Serves rendered documentation
Dashboard and API	Admin, auth, and build orchestration
Build workers	Build and publish documentation sites
MongoDB	Content store
PostgreSQL	Deployment and user metadata
Redis	Build queue and caching
Object storage	Built site bundles and static exports
Search and indexing	Docs search. The index rebuilds on publish
Identity provider	OIDC or SAML SSO for the dashboard and authenticated content
AI assistant services	Assistant and agent features	Optional

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.

Sizing

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.

Set up your platform

AWS deployments use an AWS CDK app that provisions and updates the full stack in your account. The CDK app pins container images to specific versions, so every deployment is reproducible and reviewable.

What you provide

Component	Requirement	Notes
Compute	Amazon ECS cluster	Runs the Mintlify services
Content store	Amazon DocumentDB	MongoDB-compatible
Metadata store	Amazon RDS for PostgreSQL	Deployment and user metadata
Cache and queue	Amazon ElastiCache for Redis	Build queue and caching
Object storage	Amazon S3	Built site bundles and static exports
CDN	Amazon CloudFront	Serves the docs site at the edge
Networking	VPC with public and private subnets, Application Load Balancer	Isolates workloads
TLS and DNS	AWS Certificate Manager, Amazon Route 53	HTTPS and routing for your domain
Secrets	AWS Secrets Manager	Database credentials and signing secrets
Identity	OIDC or SAML provider	Dashboard SSO

Setup

Scope the deployment

Your account team reviews your network topology, Git hosting, identity provider, and compliance requirements, then delivers the CDK app and access to versioned container images.

Configure and deploy

Set your domain, certificate, and networking in the CDK context, review the change set, and deploy.

cdk diff
cdk deploy --all

Connect Git and SSO

Grant the deployment access to your documentation repositories and connect your identity provider.

Cut over

Verify builds and search on your staging domain, then point your production DNS at the deployment.

Updates

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

Platform updates

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

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

Content updates

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.

Air-gapped deployments

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.