Why Docent?

Docent documents your application for the people who use it: help centers, user guides, onboarding, internal runbooks. That's a different job from documenting a programming library, and most of the tools you'd compare Docent to were built for the library job.

Application docs describe screens that change with every release, and the people reading them have accounts, roles, and data of their own. The tools most teams reach for keep the docs away from all of that. Hosted platforms move them onto someone else's infrastructure. Static site generators compile them into a bundle that knows nothing about your users.

Hosted platforms

Mintlify, ReadMe, and GitBook are good products. They host everything for you, the editors are pleasant, and the result looks professional with little setup. If your writers never touch a repository and the docs are mostly marketing, they're a reasonable choice.

The problem is where the docs live. Your Markdown syncs out to their platform and renders on their infrastructure, where your application's auth means nothing. Restricting a page means buying their SSO tier, not reusing the gates you already wrote. Every reader gets the same page, because the platform has no idea who's reading. Links into your app are plain URLs that break quietly when a route changes. And the docs deploy on the platform's schedule, so each release opens a gap between what the app does and what the docs say.

Static site generators

Docusaurus and VitePress fix the biggest problem: the docs move into your repository and version with your code. They're free and very good at what they were built for — open-source and developer-facing documentation. If that's what you're writing, use one of them.

For application docs, the static bundle is the wall. Every viewer gets the same HTML, so there is no such thing as a page only admins can see. You can bolt access control on around the bundle — basic auth, edge rules, a proxy — but client-side search undoes it, because the search index ships to the browser with all of your content in it. You also take on a Node toolchain and a build step beside your PHP app, plus a second artifact to deploy. Both generators support components (MDX, Vue), but a component that renders at build time has no signed-in user to render for.

What running inside the app changes

Docent is a Composer package. The docs are Markdown in your repository, rendered at request time inside your Laravel application, for whoever is looking at them. That changes what a page can do:

• authorize or audience in front matter hides a page from the nav, the search index, and the URL at once. Access control is enforced server-side, everywhere.

• Ability blocks, audiences, and conditions let an admin and a member read different instructions on the same page (dynamic content).

• Live values render from the viewer's own account, not from a screenshot that was right two releases ago.

• App links resolve named routes at render time, so moving a route updates every doc that points at it.

• Embedded Blade components run server-side with the viewer's session. Readers see the actual UI.

• Docs ship in the same pull request as the feature they describe, and validation fails CI on broken links, missing images, and links a reader isn't allowed to follow.

There's nothing extra to operate, either. Your app is already running; the docs are more routes in it.

Side by side

When Docent is the wrong choice

Some jobs belong to the other tools:

• For an open-source package or a public API, use Docusaurus or VitePress. Readers there want docs versioned per release, and there may be no Laravel app for Docent to live in.

• If the application isn't Laravel, Docent can't help. It runs inside one.

• Writers who want a full hosted CMS, with review workflows and no repository anywhere in sight, are better served by the hosted platforms. The web admin gives them browser editing, drafts, and revisions, but it isn't a full CMS.

Try it

Installation is one require and one command, and the site is up at /docs. Start with installation.