← All projects

Project

Documentation hub

• Idea • 3 min read • documentation, website, automation

Build a simple website that automatically gathers markdown documents and code documentation into one searchable place.

High-level concept

Documentation Hub is a simple site per repository that pulls together markdown notes, project analysis documents, and code documentation into one place. The goal is to turn scattered source files into a readable website that can also help with organic discovery.

Each repository can live on its own subdomain under turtlepages.com, so the hub stays separate while still being easy to browse. The project treats written analysis as part of the product surface, not as an afterthought.

The platform choice is still open. Docusaurus is one candidate, but the real question is which option handles automatic ingestion, navigation, search, and maintenance with the least friction.

Detailed steps

  • Compare Docusaurus with the other documentation-site options that fit this repository.
  • Decide on the repository-to-subdomain pattern for turtlepages.com.
  • Investigate whether Cloudflare’s DNS API can create and manage those subdomains automatically.
  • Define which folders and file types should be published automatically.
  • Decide how markdown notes and code documentation should be merged into one content model.
  • Prototype a first version that indexes the existing repository content.
  • Add navigation, search, and a layout that makes the site easy to scan.
  • Choose a deployment path and update flow that keeps the site in sync with the source files.
  • Review the first version for gaps, noise, and broken assumptions.

Step 1: Compare the options

Evaluate the candidates against a small set of criteria:

  • markdown support
  • code documentation ingestion
  • search
  • theme and layout control
  • deployment simplicity
  • long-term maintenance cost

Keep the comparison practical. The winner should be the option that makes it easiest to publish the existing material without turning the site into another system to manage.

Step 2: Define the content sources

Decide what the hub should collect:

  • any markdown file in the repository
  • generated code documentation
  • other markdown files that should be public

This step should also settle what stays private, what gets published as-is, and what needs a rewrite before it can be shown publicly.

Step 3: Map repositories to subdomains

Decide how repository names turn into public hostnames. Keep the pattern predictable so a repository can be matched to a site without manual bookkeeping.

The subdomain setup should stay compatible with Cloudflare DNS management, so new sites can be added without creating a separate operational process for every repository.

Step 4: Build the publishing flow

Prototype the simplest working pipeline for turning source files into a site. Start with the current repository structure, then add whatever parsing, frontmatter handling, and doc extraction the chosen platform needs.

The first pass should prove that the content can stay in one source of truth while still showing up on a simple website.

Step 5: Shape the site

Add the parts that make the hub useful:

  • clear navigation
  • search
  • readable article pages
  • tags or categories
  • a clean path from source content to published pages

The site should feel like a documentation index, not a generic blog.