Add custom developer portals doc

[chitalian]

Stacked on #6723. Merge that first; this PR targets its branch.

Adds deploy/custom-portal: custom presentation layer engagements on top of a self-hosted deployment, with a features table (what ships and which system backs it), architecture, and engagement phases. Adds the nav entry.

🤖 Generated with Claude Code

---

Note

Low Risk
Documentation and navigation only; no application or deployment logic changes.

Overview
Adds deploy/custom-portal, a new Deploy doc for Enterprise custom portal engagements on top of self-host.

The page explains Mintlify-built bespoke presentation layers (marketplaces, sign-in, credentials, subscriptions, support) while content stays in the CMS, includes a features table (what ships vs Mintlify vs customer backends), a Mermaid architecture diagram, phased engagement steps, and links to sales and self-host.

docs.json registers deploy/custom-portal in the Deploy nav immediately after deploy/self-host.

^{Reviewed by Cursor Bugbot for commit 4b98a49. Bugbot is set up for automated code reviews on this repo. Configure here.}

[ethanpalm]

Suggested change

	Custom portals are scoped engagements on an [Enterprise plan](https://mintlify.com/pricing?ref=custom-portal), built on a [self-hosted deployment](/deploy/self-host). Reach out to your account team to scope one.
	Custom portals require an [Enterprise plan](https://mintlify.com/pricing?ref=custom-portal) and a [self-hosted deployment](/deploy/self-host). Reach out to your account team to scope one.

[ethanpalm]

Suggested change

For some platforms, documentation is one surface of a larger product: an API marketplace, a partner portal, a developer experience with sign-in, credentials, and support built in. For those cases, Mintlify goes beyond hosting your docs. We design, build, and maintain a complete custom presentation layer that replaces your existing portal front end, while your team authors everything through the Mintlify CMS.

For some platforms, documentation is one surface of a larger product—an API marketplace, a partner portal, or a developer experience with sign-in, credentials, and support built in. Mintlify supports those use cases by designing, building, and maintaining a custom presentation layer that replaces your existing portal front end, while your team authors content through the Mintlify editor or a Git-backed workflow.

tell all my haters the emdash will never die

[ethanpalm]

Suggested change

	You keep your backend. The portal integrates with your existing APIs, gateway, and downstream systems, which stay owned and operated by your team.
	The portal integrates with your existing APIs, gateway, and downstream systems, which remain owned and operated by your team.

[ethanpalm]

Suggested change

	| Custom presentation layer | A full front-end application in your design system, deployed inside your environment. Not a themed template, a bespoke build | Mintlify, alongside the self-hosted platform |
	| Product and catalog pages | Marketplace, product discovery, and documentation surfaces | Mintlify CMS content |
	| Sign-in | Authenticated sessions across the portal | Your identity provider |
	| Applications and credentials | Application registration and credential management | Your backend APIs |
	| Subscriptions | Product and plan subscriptions | Your backend APIs |
	| Profiles and notifications | User profiles and notification centers | Your backend APIs |
	| Support | Support ticket creation and tracking | Your backend APIs |
	| Search | Login-aware search scoped to what the user can access | Mintlify platform |
	| Personalized content | Entitlement and group-based filtering applied server-side at render time, so users only see the products and pages they have access to | Mintlify platform and your identity provider |
	| Ongoing releases | Versioned releases with upgrade guides, the same operating model as any [self-hosted deployment](/deploy/self-host#updates) | Mintlify |
	| Custom presentation layer | A full front-end application in your design system, deployed inside your environment | Mintlify, alongside the self-hosted platform |
	| Product and catalog pages | Marketplace, product discovery, and documentation surfaces | Content maintained on Mintlify |
	| Sign-in | Authenticated sessions across the portal | Your identity provider |
	| Applications and credentials | Application registration and credential management | Your backend APIs |
	| Subscriptions | Product and plan subscriptions | Your backend APIs |
	| Profiles and notifications | User profiles and notification centers | Your backend APIs |
	| Support | Support ticket creation and tracking | Your backend APIs |
	| Search | Login-aware search scoped to what the user can access | Mintlify platform |
	| Personalized content | Entitlement and group-based filtering applied server-side at render time, so users only see the products and pages they have access to | Mintlify platform and your identity provider |
	| Ongoing releases | Versioned releases with upgrade guides, the same operating model as any [self-hosted deployment](/deploy/self-host#updates) | Mintlify |

[ethanpalm]

Suggested change

	## Authoring stays a CMS flow
	The custom front end doesn't change how content gets written. Non-technical authors use the web editor; engineers work in git-backed Markdown with pull-request review. Every change flows through your repository's review process with a full audit trail, and publishing triggers builds that update the portal automatically. No front-end deploy is needed to change content.
	## Authoring flow
	The custom front end doesn't affect how content gets written. Maintain content with the editor or a local Git-based workflow. Every change flows through your repository's review process with a full audit trail, and publishing triggers builds that update the portal automatically. Content changes do not require a front-end deploy.

[ethanpalm]

Suggested change

	Everything runs inside your network boundary on the platforms described in [self-host](/deploy/self-host): your cluster, your data stores, your observability stack, no third-party egress. Your downstream systems of record are untouched; the portal consumes them through the APIs you already expose.
	The custom presentation layer and Mintlify platform run inside your network boundary, using your cluster, data stores, and observability stack, with no third-party egress. Your downstream systems of record remain unchanged; the portal accesses them through your existing APIs.

[ethanpalm]

Suggested change

	Your account team maps the portal surfaces, your design system, and the backend APIs the portal will consume, and agrees on an integration contract with your platform team.
	Your account team maps the portal surfaces, your design system, and the backend APIs the portal consumes, and agrees on an integration contract with your platform team.

[ethanpalm]

Suggested change

	description: "Ship a fully custom presentation layer and developer portal on top of a self-hosted Mintlify deployment, built and maintained by Mintlify."
	description: "Deploy a fully custom developer portal on top of self-hosted Mintlify, designed and built by Mintlify and delivered through versioned releases."

[ethanpalm]

Suggested change

	| Product and catalog pages | Marketplace, product discovery, and documentation surfaces | Mintlify CMS content |
	| Product and catalog pages | Marketplace, product discovery, and documentation surfaces | Self-hosted Mintlify platform |

[ethanpalm]

Suggested change

	The presentation layer sits between your users and two backends: the Mintlify platform for content, search, and personalization, and your own services for everything transactional.
	The custom presentation layer integrates with the self-hosted Mintlify platform for content, search, and personalization; your API gateway for applications, subscriptions, and support; and your identity provider for authentication.

[ethanpalm]

Suggested change

	<Step title="Public surfaces first">
	The engagement typically lands design system parity and public content surfaces first, so you can validate the experience against your existing portal before switching anything over.
	<Step title="Public surfaces first">
	The engagement typically implements your design system and public content surfaces first, so you can validate the experience against your existing portal before cutover.

[ethanpalm]

Suggested change

	<Step title="Search, personalization, and AI">
	Login-aware search and server-side personalization complete the experience. AI features ship disabled and turn on only after your security or AI governance review.
	<Step title="Search, personalization, and AI">
	Login-aware search and server-side personalization complete the core experience. Optional AI features remain disabled disabled until your security or AI governance team approves them.