PRIMARY AUDIENCE
Readers of technical playbooks, prospective clients exploring engineering approaches, internal editors and contributors, and the NASA assistant that retrieves relevant knowledge.
Headless content platform · Technical publishing
Neubofy Knowledge Base Engine
Internal infrastructure
One publishing engine for technical playbooks, specifications, and native HTML mini-sites.
Interface overview
12 (7 playbooks + 5 specifications)Public content items
admin.kv.neubofy.inAdmin portal
backend.kv.neubofy.inAPI host
01 / WHY
The problem I chose to solve
The most useful way to understand this project is to start with the friction behind it, then examine the system choices made to address that friction.
A conventional blog or static markdown folder is awkward when technical documentation and campaign-specific mini-sites need separate publishing rules, permissions, and rendering. Content also has limited reuse if each frontend has to rebuild its own content-management logic.
I designed the Knowledge Base as an edge-native, decoupled publishing engine. It separates writing and governance from public rendering and supports two kinds of content: structured Markdown articles for playbooks/specifications, and full HTML pages for unconstrained landing-page experiences. The same knowledge base can support human readers and provide material for retrieval-based AI support.
02 / WHO IT SERVES
Where it fits in the real world
A strong implementation has a bounded audience and context. These are the use cases supported by the current design—not a claim that all of them have been validated at scale.
WHAT MAKES IT DISTINCT
- Two content formats: GitHub-Flavored Markdown and native HTML pages
- Dedicated administrative SPA and REST API, separate from the public reader
- Role-based contributor/editor/admin workflow and audit trail
- Structured content pages with headings, table of contents, syntax highlighting, metadata, and schema markup
- Cache invalidation tied to content changes
03 / PRODUCT SURFACE
What the system actually does
An overview of key capabilities and system features.
CAPABILITY / 01
Article publishing
Markdown articles can render syntax-highlighted code blocks, TOCs, summaries, and structured metadata.
CAPABILITY / 02
HTML page publishing
Raw HTML documents can be managed as mini-sites rather than constrained inside a markdown template.
CAPABILITY / 03
Admin governance
Role-based permissions, content management, draft/publication workflows, and audit logs.
CAPABILITY / 04
Authentication options
The README documents password, WebAuthn passkeys, magic links, GitHub OAuth, and Google OAuth pathways.
CAPABILITY / 05
Edge delivery
Cloudflare D1 stores structured data; the Worker API and cache layer serve public content.
CAPABILITY / 06
AI knowledge reuse
NASA’s retrieval index is described as a separate Vectorize layer that can fetch semantically relevant information.
04 / SYSTEM MAP
Architecture & data flow
Architecture and system flow overview.
LAYER / 01
Editor dashboard
React/Vite administrative SPA on Cloudflare Pages.
LAYER / 02
REST API
Hono Worker handles access checks, validation, content endpoints, and cache control.
LAYER / 03
Structured storage
Drizzle ORM maps application data to Cloudflare D1.
LAYER / 04
Public reader + AI retrieval
Next.js renders articles/HTML pages; published knowledge can also feed the NASA Vectorize index.
IMPLEMENTATION STACK
Cloudflare Workers, Hono, D1, Drizzle ORM, Cloudflare Pages, React 18, Vite, React Query, Next.js 15 / React 19 on the public reader, Cloudflare Vectorize for AI retrieval.
Cloudflare WorkersHonoD1Drizzle ORMCloudflare PagesReact 18ViteReact QueryNext.js 15 / React 19 on the public readerCloudflare Vectorize for AI retrieval.
05 / ENGINEERING JUDGMENT
Decisions behind the implementation
Engineering choices and design decisions behind the implementation.
- Keep content data independent from the public website’s layout.
- Give raw HTML its own publishing model rather than forcing every page into Markdown.
- Treat authentication, authorization, caching, and auditability as part of the content engine—not add-ons.
06 / SCOPE & BOUNDARIES
Technical Considerations
Key technical details and system scope considerations.
- Private enterprise implementation available upon client request.
- The README claims sub-20ms edge response times; that is a design/documentation claim, not a verified benchmark in this report, so it should not be marketed as a measured guarantee.
- A private API and credential setup should never be exposed in project screenshots or public source snippets.
07 / NEXT ITERATION
What I would improve next
The next step is not simply adding features. It is increasing reliability, evidence quality, user trust, and clarity about the boundaries of the system.
NEXT / 01
Publish a redacted architecture diagram and test methodology for performance/security claims.
NEXT / 02
Track content freshness and ownership for each public article.
NEXT / 03
Make the publishing-to-vector-index refresh path observable so AI answers can be traced to updated sources.
08 / SOURCES
Sources & Resources
Project repositories and resource links.