How to self-host a Mintlify alternative on Cloudflare

1. Decide what you are migrating

Start with an inventory of documentation routes, MDX components, images, navigation and OpenAPI specifications. Identify requirements beyond publishing: authenticated readers, search, AI answers, previews and team permissions. Each requirement needs an implementation or a deliberate decision to leave it out.

If you mainly want a smaller bill, check Mintlify pricing first. A managed free plan may already fit your needs. Use the alternatives shortlist if you prefer a different authoring ecosystem.

2. Generate one Heyo Docs project

The upstream README documents this npm creator command:

npm create @heyo-sh/heyo-docs@latest

The creator asks for a project directory, framework, deployment target, theme and package manager, then prints the commands for the generated project. Choose the Cloudflare target and follow that output. @latest may change after the reviewed snapshot, so check the generated files rather than assuming they match this guide exactly.

We did not run this command for the guide. It is a documented starting point, not evidence that your account or site is already configured.

3. Inspect the framework’s Cloudflare configuration

The reviewed repository contains three different deployment templates:

Framework path	What the captured Wrangler template declares	What to check in your generated project
Astro	A project-name placeholder and compatibility settings	The chosen adapter, generated entrypoint and build output
Next.js	.open-next/worker.js plus .open-next/assets with an ASSETS binding	That the framework build actually generates both paths
React Router	./workers/app.ts and ./build/client	The Worker entrypoint and client asset build

These are alternative configurations. They do not demonstrate that three apps run together. No D1, KV or R2 bindings appear in these captured templates. Custom server logic and optional providers can add infrastructure later.

The Heyo Docs project page links the pinned files and records limitations in the architecture source analysis. Follow the exact file paths for your selected framework.

4. Preview a representative content sample

Follow the generated project’s development and build commands. Add a normal guide, a component-heavy page and an API reference page. Check internal links, anchors, image paths, code rendering, search, navigation and mobile readability.

Build success alone is insufficient. Inspect the production output or preview for the chosen adapter, then check the routes you actually expect readers and crawlers to visit.

5. Deploy, then measure what executes

Use the framework’s documented Cloudflare deployment path after reviewing its build output and Wrangler configuration. Verify the published pages, custom domain, redirects, failure handling and rollback process.

Static asset requests have no Cloudflare request charge. Requests that invoke a Worker, including dynamic rendering, follow Workers pricing and limits. Authentication, server routes and optional AI providers can therefore change costs. Measure the actual workload before treating hosting as free.

6. Cut over only after the pilot works

Preserve public URLs or create redirects, check metadata and canonical URLs, and confirm that important pages are reachable through navigation. Give someone ownership of dependency updates and publishing failures. The migration is complete when readers can use the documentation and your team can maintain it.

For the decision before implementation, read Heyo Docs vs Mintlify. For the actual source, license and screenshot, open the reviewed Heyo Docs project.