# Free Mintlify and GitBook Alternative: Docs In Your App

> Hosted docs tools start at $0 and climb fast. If your guides can live at /docs on your own domain, 19 markdown files are already doing it here.

Source: https://boringpush.com/blog/free-mintlify-gitbook-alternative-docs

## Your docs are a second site with a second bill

You ship a product at `yourapp.com`, then someone asks for docs. The default move is a separate host: Mintlify, GitBook, a docs subdomain, another login, another invoice. The docs look good, and for a team with a writer, that is often the right call.

For a solo founder, the docs are usually a folder of text that describes the product you already built. They change when the code changes, and they ship with the same deploy. Paying a second platform to host that folder can wait.

BoringPush keeps the docs inside the app, at `/docs`, built from markdown files in `data/docs/`. This post shows the files, the code, and the limits, so you can decide whether a hosted tool still earns its price.

## What the hosted plans cost

Mintlify and GitBook numbers come from their official pricing pages, checked on 2026-10-21.

| | Mintlify Starter | GitBook Free | BoringPush docs |
|---|---|---|---|
| Price | $0 | $0 | $199 once for the kit |
| Editor seats | 5 | 1 free user | Anyone who can commit |
| Custom domain | Yes | No, Essential and up | Your app's domain |
| Where content lives | Git repo, hosted by Mintlify | GitBook | Markdown in `data/docs/` |
| Search | Yes | Yes | No |
| AI assistant | Pro and up | Essential and up | No |
| API playground | Yes | Yes | No |
| Browser editor | Yes | Yes | No |

Mintlify Pro is $450 a month billed annually, or $540 billed monthly. GitBook Essential is $65 per site per month plus $12 per user per month, and Ultimate is $249 per site plus $12 per user, both billed annually. Enterprise is a quote on both.

Both free tiers are real products. Mintlify Starter includes a custom domain, five editor seats, authentication, an MCP server and an API playground. GitBook Free includes GitHub sync, preview deployments, an MCP server and LLM-friendly output for one user.

If you need a hosted editor and a searchable docs site this week, those are fair prices. The built-in version is for a different shape of work.

## What is in `data/docs` today

There are 19 markdown files. The first is `00-index.md`, which renders at `/docs` itself. The rest are numbered guides, from `01-get-started.md` to `18-ai-assistants-mcp.md`, plus an `assets` folder for images.

Each file starts with four frontmatter fields:

```md data/docs/04-auth.md
---
title: "Auth — Google, Magic Links, Dev Login, Sessions"
description: "Adapters per database, JWT sessions, stale-session guard, admin allowlist."
date: "2026-09-19"
tags: ["docs", "auth"]
---
```

The body is ordinary Markdown. Headings, code fences, tables, links and images all work. The docs renderer applies the same sanitizer as the blog, so scripts, iframes and inline event handlers are stripped before the HTML reaches the page.

## How a new guide is added

**Step 1 — Write the file.** Drop `19-webhooks.md` into `data/docs/`, with a title and description at the top. The route is built from the filename: `data/docs/19-webhooks.md` becomes `/docs/19-webhooks`.

**Step 2 — Add it to the sidebar.** `app/(pages)/docs/Nav.js` holds four hardcoded sections: Get Started, Learn Boring, Ship It and Operate. Add the slug to the right `slugs` array. Skip this step and the page still builds and works at its URL, but no link appears in the sidebar.

**Step 3 — Deploy.** `generateStaticParams()` in `app/(pages)/docs/[slug]/page.js` reads every `.md` file in the folder, so the new guide is built with the rest of the app. `next-sitemap.config.js` gives each `/docs/<slug>` entry the date from its frontmatter.

That is the whole publishing flow. There is no import screen, no content database and no second login.

## What each page gets for free

**A sidebar and an in-page list.** The layout reads every markdown file, sorts by filename and passes the titles to `Nav.js`. On the page, each `##` heading becomes an item in "In this guide", capped at the first eight.

**A copy button.** `CopyBtn.js` copies the raw markdown to the clipboard. That is handy when a reader wants to paste the guide into an AI assistant and ask a question about it.

**An Open Graph card.** `app/(pages)/docs/[slug]/opengraph-image.tsx` reads the guide title and draws a 1200 by 630 share image with Next's `ImageResponse`, over a photo backdrop. The index has its own card titled "Convention over configuration".

**Interactive figures where they earn a place.** The `VISUALS` map in the slug page attaches one component to a guide. `02-project-structure` gets `RequestFlow`, `03-config-env` gets `OneSwitch`, and `11-deployment` gets `DeployMap`. A guide can place its visual with an HTML comment marker, or the visual renders at the end.

**Image paths that survive the move.** Markdown images written as `assets/foo.png` are rewritten to `/docs/assets/foo.png`, so the same files work in the editor and on the site.

## What it does not have

There is no search in the docs code. A reader can use the browser's find or the sidebar, and that is it. A real docs site with fifty guides needs search, and this does not ship one.

There is no version switcher, no changelog, no review workflow and no permissions layer. Every guide is public, and editing means editing a file and deploying. There is no AI answer box, no API playground, no feedback widget and no analytics specific to docs.

The visual polish is also yours. The layout is a header, a left index and a content column, styled with the app's Tailwind tokens. Mintlify and GitBook have teams making that shell better every month.

## When you should still pay for Mintlify or GitBook

Pay for a hosted docs tool when docs are a product surface, not a folder. Search, AI answers, API references that update from an OpenAPI spec, translations, review workflows and per-page permissions are real work, and both platforms have spent years on them.

Pay when a non-engineer writes the docs. A block editor and comments beat git for a support team, and a preview deployment beats asking someone to run the app locally.

Pay when the docs need to sit on their own subdomain with their own access rules. BoringPush docs live on the app's domain and share its deploy. That is the point, and it is also the constraint.

## FAQ

### How many docs ship with BoringPush?

There are 19 markdown files in `data/docs/`. One is the index that renders at `/docs`, 18 are numbered guides, and there is an `assets` folder for images.

### Do I have to add a file to the sidebar by hand?

Yes. The route is generated from the folder, but the sidebar is a hardcoded list in `app/(pages)/docs/Nav.js`. A file that is not in one of its four sections still works at its URL but stays out of the navigation.

### Can I use my own domain?

The docs use the same domain as the app, so there is no separate DNS record or certificate. A guide is at `yourapp.com/docs/<slug>`, and the app's deploy ships it.

### Are the docs in the sitemap?

Yes. `next-sitemap.config.js` treats `/docs/<slug>` as a weekly page with priority 0.6, and takes its last-modified date from the guide's frontmatter. The index at `/docs` gets priority 0.8.

### Can I keep using Mintlify and add these docs later?

Yes. The docs folder is plain markdown, so the content moves either way with a copy. The renderer is a few small files, and none of it touches the database or the billing code.

## Keep reading

- [Free Ghost Alternative: A Markdown Blog Built In](/blog/free-ghost-blog-alternative-markdown) — the same file-based idea for posts
- [AGENTS.md vs CONVENTIONS.md](/blog/agents-md-vs-conventions) — how the docs and the agent rules divide the work
- [The Indie Hacker Stack, Without the Subscriptions](/blog/boringpush-indie-hacker-stack) — what else is built in

[Get BoringPush →](/#get)