Skip to content

Repository files navigation

NativeHub logo

NativeHub

Practical guides and resources for cloud native development

A production-quality documentation and learning hub for Kubernetes, containers, and the tooling that runs them. Concepts explained properly, guides you can follow end to end, and commands that actually work.

CI Link check License: MIT Docusaurus Node

Live demo — nativehub-chi.vercel.app

The NativeHub homepage in dark mode, showing the hero section and a kubectl terminal panel


Screenshots

A documentation page showing the sidebar, table of contents, callouts, and syntax-highlighted YAML

Docs — sidebar, TOC, callouts, code tabs

The blog index showing post cards with dates, reading time, author, and tags

Blog — six long-form technical articles

The resources page showing the four-stage learning roadmap component

Resources — curated links and a roadmap

The NativeHub homepage hero in dark mode

Home — hero, feature cards, latest posts


Features

  • 11 in-depth doc pages — six concept pages under Learn, five task walkthroughs under Guides
  • 6 long-form blog posts — Pods vs Deployments, the containerd/runc stack, OCI bundles, and more
  • 3 searchable cheat sheets — kubectl, docker, and helm, filterable by category
  • Curated tool directory — 18 real CLI tools with licences and upstream links, no affiliate junk
  • Learning roadmap — a four-stage path from container basics to production practices
  • Designed light and dark themes — a full token system, not the stock Docusaurus palette
  • Follows your system theme — with an explicit System / Light / Dark control that persists
  • 7 reusable React components — FeatureCard, CalloutBox, CheatSheetTable, CodeTabs, BlogPostCard, LearningRoadmap, ThemeToggle
  • Live homepage blog preview — generated by a custom Docusaurus plugin, never hand-maintained
  • Offline search — build-time index across docs, blog, and pages; no external service
  • Responsive — verified at mobile, tablet, and desktop widths
  • Accessible — WCAG AA contrast in both themes, keyboard navigable, prefers-reduced-motion respected
  • RSS and Atom feeds — no newsletter, no tracking
  • CI on every PR — build, broken-link check, ESLint, Prettier, and TypeScript

Tech stack

Layer Choice Why
Framework Docusaurus 3.10 Docs and blog plugins, MDX, versioning-ready, first-class search
UI React 19 + TypeScript Typed components, strict tsc --noEmit in CI
Styling Tailwind CSS 3 + CSS Modules + Infima Tailwind for layout utilities, modules for component styles, Infima for base
Content MDX 3 Markdown that can import real React components
Syntax highlighting prism-react-renderer YAML, bash, Dockerfile, JSON, Go, TOML, diff
Quality ESLint 8 + Prettier 3 Zero-warning lint gate, formatting checked in CI
CI/CD GitHub Actions Build, link check, lint, deploy to Pages
Link checking lychee External links, plus a weekly scheduled sweep
Hosting Vercel Auto-deploy from main, preview URL per PR

Architecture

Project structure: .github/workflows, docs/learn and docs/guides, blog, src/components, src/pages, src/css and src/theme, static, and the root config files, each annotated with its purpose

Three design decisions worth knowing

Tailwind is additive, not a replacement. preflight and container are disabled in tailwind.config.js so Infima keeps ownership of base element styles and its own .container. Tailwind supplies layout and spacing utilities on top; component-specific styling lives in CSS Modules. This avoids the reset war that usually follows dropping Tailwind into Docusaurus.

One token system, two themes. src/css/custom.css is layered: design tokens (--nh-*) at the top, Infima variable overrides (--ifm-*) pointing at them next, then component chrome. Dark mode redefines tokens only. Components never hard-code a colour, which is why both themes look deliberate rather than inverted.

The homepage blog preview is generated. A small plugin in docusaurus.config.ts reads each post's front matter at build time, maps tag keys to their labels from blog/tags.yml, estimates reading time, and exposes the result as global data. Publishing a post updates the homepage with no other edits.


Local development

Requirements: Node.js 20+ (CI uses 22) and npm 10+.

git clone https://github.com/mdryaaan/nativehub.git
cd nativehub

npm install
npm run start      # http://localhost:3000/

Note

Local dev serves from /, the same paths as production — what you see locally is what deploys.

npm run build      # production build; fails on broken links and anchors
npm run serve      # serve the production build locally

All scripts

Command What it does
npm run start Dev server with hot reload
npm run build Production build into build/
npm run serve Serve the production build
npm run typecheck tsc --noEmit
npm run lint ESLint over src/, zero warnings tolerated
npm run lint:fix ESLint with autofix
npm run format Prettier, write mode
npm run format:check Prettier, check mode — what CI runs
npm run clear Clear the Docusaurus cache

Run this before opening a PR — it is exactly what CI runs:

npm run build && npm run lint && npm run format:check && npm run typecheck

How content is organised

Four places, four different jobs:

Location Route Use it for Shape
docs/learn/ /docs/learn/* Explaining a concept Reference. Read in any order.
docs/guides/ /docs/guides/* Accomplishing a task Numbered steps, start to finish.
blog/ /blog/* An article with a date and a view Narrative, with a truncation marker.
src/pages/ /tools, /resources, /about A page that is not primarily prose Bespoke React.

Docs are registered explicitly in sidebars.ts — nothing is autogenerated, so a new page will not appear until you add its id. Each page carries an "Edit this page" link and a "Last updated" stamp derived from git history.

Blog posts need a slug, a date, an author defined in blog/authors.yml, tags defined in blog/tags.yml, and a {/* truncate */} marker. The build is configured to throw on unknown authors, unknown tags, and untruncated posts, so mistakes fail fast rather than shipping.

Pages are plain React routes. They import the same components MDX does, so a cheat sheet looks identical whether it appears on /tools or inside a blog post.

Full instructions for each are in CONTRIBUTING.md.


Quality and accessibility

CI runs on every pull request:

Check Tool Gate
Build docusaurus build Fails on any broken internal link or anchor
External links lychee Fails on dead links; weekly cron opens an issue
Lint ESLint 8 --max-warnings=0
Formatting Prettier 3 --check
Types TypeScript tsc --noEmit

Accessibility checklist

Treated as a build requirement rather than a nice-to-have. Every page is checked against:

  • Contrast — body text meets WCAG AA (4.5:1) in both themes; link and callout colours are lightened in dark mode specifically to clear the threshold
  • Heading hierarchy — exactly one h1 per page, levels step down one at a time
  • Keyboard navigation — every interactive element is reachable and operable by keyboard
  • Visible focus — a 2px focus ring is never suppressed; :focus-visible is styled globally
  • Alt text — meaningful on informational images, aria-hidden="true" on decorative SVGs
  • Semantic landmarksheader, main, nav, footer, plus a skip-to-content link
  • Labelled controls — search inputs, filter groups, and toggles have accessible names and aria-pressed state
  • Reduced motion — all animation and transition durations collapse under prefers-reduced-motion: reduce
  • No horizontal scroll — wide tables and code blocks scroll inside their own container, never the page
  • Theme persistence — the colour choice is stored in localStorage and applied before first paint, so there is no flash of the wrong theme

To audit a build yourself:

npm run build && npm run serve
npx lighthouse http://localhost:3000/ \
  --only-categories=accessibility,performance,seo,best-practices --view

Deployment

Hosted on Vercel at nativehub-chi.vercel.app. Pushes to main deploy to production; every pull request gets its own preview URL.

vercel.json holds the whole configuration — framework preset, output directory, clean URLs, immutable caching for fingerprinted assets, and baseline security headers — so importing the repo at vercel.com/new needs no manual settings.

One thing to know before changing docusaurus.config.ts: the canonical url is resolved at build time, not hard-coded. Production builds use VERCEL_PROJECT_PRODUCTION_URL; preview builds use VERCEL_URL, so a preview never claims to be the production site in its canonical tags or sitemap. baseUrl is always /, which is why local dev and production behave identically.


Contributing

Corrections are the most valuable contribution — this site is only useful if it is right.

Every doc page has an Edit this page link that takes you straight to the source file. For anything larger, CONTRIBUTING.md covers the environment setup, how to add a doc page, a blog post, or a component, the writing standard, branch and commit conventions, and the PR checklist.


License

MIT © 2026 Md Raiyan

Content and code alike. Reuse it, adapt it, teach from it — attribution is appreciated but not required.

About

NativeHub — Practical guides and resources for cloud native development. Kubernetes, containers, Helm, and the tooling that runs them.

Topics

Resources

Contributing

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages