Use the existing project

This idea now points to a reviewed repository. The original build proposal is preserved below.

Existing project · Free tier eligible

Heyo Docs

By heyo-sh

Self-managed MDX documentation, navigation, search and OpenAPI reference pages; no claim of hosted-team administration or complete proprietary documentation-service parity.

A small Cloudflare documentation deployment can fit static-asset and Worker Free allowances. Use the creator Cloudflare target and its generated framework adapter; dynamic routes must remain below the Free CPU/request ceilings. Optional AI chat/provider services are excluded.

Explore Heyo Docs →

Original build proposal

The concept below is preserved for reference. Use the linked project above for its actual features, README and infrastructure.

Browse existing projects and remaining proposals →

Existing project selected

Original concept

Mintlify on Cloudflare

Git-backed docs, search, API reference pages, feedback, and AI answers on Cloudflare.

replaces Mintlify D1 Pages R2 Vectorize Workers Workers AI

would replace

Mintlify· documentation

AI-native documentation platform for developer-facing products.

How it would work

A URL goes in, an API-ready result comes out. These are the stages the request flows through.

map01
Map the rented workflow
Identify the small-team job that actually needs replacing.
→
build02
Assemble the Cloudflare loadout
Pick the primitives that cover the core data, compute, auth, and delivery path.
→
ship03
Publish the useful version
Release a deployable build with limits, setup notes, and maintenance tradeoffs.

Concrete jobs it does

If you're paying Mintlify for any of these, the proposed build would let you stop.

→Cover the small-team workflow people actually rent the SaaS for
→Expose a simple, deployable API
→Persist the right data in D1 and the right artefacts in R2
→Stay maintainable by one or two engineers

Config knobs

What you'll be able to tune from day one.

Workflow scope: core team workflow only
Deployment target: Cloudflare Workers + supporting primitives
Access model: simple auth and admin controls
Limits: documented scale and maintenance boundaries

proposed architecture

The Cloudflare loadout, wired together.

Architecture

Overview inferred from the listed Cloudflare services. Routes and connections have not been verified.

Public interface

Surfaces1

client / caller

interface not yet reviewed

→

↓

App

Pages

entry

static + functions

Supporting services

Workers

backing

request handler

→

↓

Bindings

what each tool does

Cloudflare feature

Function in the proposed app

D1tool 01

Track crawl jobs, pages, status, users, limits, and API keys.

Pagestool 02

Pages

Use Pages for the part of the owned app that needs this platform capability.

R2tool 03

Store raw HTML, screenshots, markdown output, and crawl artefacts.

Vectorizetool 04

Vectorize

Index extracted content for semantic search and retrieval.

Workerstool 05

Workers

Public API, routing, auth checks, rate limits, and orchestration glue.

Workers AItool 06

Workers AI

Classify pages and extract structured fields when deterministic parsing is not enough.

will build

+The core workflow small teams actually use every week.
+A deployable Cloudflare-native version with clear setup steps.
+Basic auth, data storage, admin screens, and operational visibility.
+A writeup that explains the useful limits and maintenance burden.

will not build

-A pixel-perfect clone of the SaaS being replaced.
-Enterprise governance, compliance guarantees, or managed support.
-Every advanced feature that only large teams need.
-A promise that replacing the rented tool is always the right call.

readme