Ghost is known as a publishing platform. Most CTOs think of it as a blog engine. That framing misses what Ghost actually is at the infrastructure level: a headless CMS with a well-documented REST API, a Lexical-based content model, granular access control, and a built-in member authentication system. For a certain class of internal tools, it is dramatically faster to build on Ghost than to build from scratch.
Specifically: knowledge bases, internal documentation portals, team wikis, and process documentation libraries. Tools that need structured content, search, access control, and the ability for non-technical team members to create and edit content without touching code.
What Ghost Provides Out of the Box
The Content API is a read-only REST API that returns posts, pages, tags, and authors in structured JSON. No authentication required for public content; API key required for member-only content. This is the interface your internal tools consume.
The Admin API is a write API for creating and updating content programmatically. It accepts Lexical JSON for rich content. Authentication via JWT. This is the interface your automation tools write through.
Members is a built-in authentication system that supports free and paid tiers, email and password login, and Magic Link authentication. For an internal knowledge base, set all content to members-only, configure the signup to require email verification on your domain, and you have access control without building an auth system.
Architecture Pattern: Internal Knowledge Base
The setup for an internal knowledge base: a Ghost instance (self-hosted or Ghost Pro), all content set to members-only visibility, member signup restricted to your company email domain via a signup validation script in Ghost's portal settings, and a Next.js or SvelteKit frontend consuming the Content API.
The frontend is optional. Ghost's built-in Casper theme works perfectly well for a simple knowledge base. The frontend layer makes sense when you need deep integration with other internal systems such as Slack links, JIRA issue references, or custom search facets.
The API-First Approach
The more powerful use case is treating Ghost as a content backend for a custom internal tool. A runbook management system, an incident post-mortem library, a decision log: any of these can be built as a thin frontend consuming the Ghost Content API with Ghost handling content storage, search, and access control.
Example: an incident post-mortem library. Post-mortems are created in Ghost with a custom tag taxonomy (severity, service affected, root cause category). A React frontend consumes the Content API and provides filtered views. The post-mortem template is a Ghost page with the standard sections pre-filled. The whole thing is searchable via the Ghost search API. Time to build from scratch with a custom backend: 2 to 4 weeks. Time to build on Ghost: 2 to 3 days.
Limitations to Know
Ghost is not a database. If your internal tool needs complex relational queries, custom data types beyond what the post and page and tag model supports, or high-frequency writes, Ghost is the wrong foundation.
Concurrent editing is not supported. Ghost does not have Google Docs-style collaborative editing. For documentation that multiple people edit simultaneously, this is a real limitation.
The access control model is binary (public or members-only) at the post level. Role-based access at the content level requires a custom implementation on top of the Content API.
For the use cases where it fits, Ghost eliminates enough infrastructure work that the fit and limitation tradeoff is clearly positive. The CTO who has spent two days building something on Ghost that would have taken three weeks custom has already made the case.
Originally published on Tech at Crescevo — subscribe free for more.
Top comments (0)