Ghost - Moses Yebei

The Problem

Ghost is a headless Node.js CMS for professional publishing, handling memberships, subscriptions, and newsletters. The core problem it solves is giving publishers a modern, self-hostable platform that separates content management from presentation, with built-in monetization through memberships and subscriptions rather than relying on third-party services.

What This Does

This repository is a monorepo collection of five self-contained projects, not a single codebase. The ghost/ directory (4,531 files) contains the core CMS and admin application, while apps/ (2,016 files) holds separate frontend applications: portal for member signup/login, comments-ui for comment threads, announcement-bar for site notifications, and admin-x-* for the modern admin interface. The e2e/ directory (283 files) contains Playwright end-to-end tests.

The stack is predominantly JavaScript (3,106 files) with TypeScript (790 files) and TSX (853 files). The admin app runs on Ember.js within ghost/admin, while the apps use React and Vite. Package management is pnpm, with Docker and GitHub Actions for CI/CD.

How It Is Wired

Execution starts at several independent entry points. The portal app's componentDidMount in apps/portal/src/app.js reaches 194 functions—the widest reach in the repo—and handles member-facing flows. The announcement bar's init in apps/announcement-bar/src/index.js reaches 111 functions. These are separate applications that talk to the Ghost API rather than sharing code.

The code's internal call graph shows 1,811 resolved call edges. The most-called function is t (called from 118 places), a translation helper in apps/portal/src/utils/errors.js—changing it breaks nearly everything in the portal. makeRequest (called from 29 places) handles API calls, while query (26 places) in ghost/admin/app/adapters/base.js is the admin's data-fetching backbone. The ghost/admin/app/controllers/lexical-editor.js is the largest hub with 66 functions, and it reads/writes files, suggesting it handles editor state persistence.

Only 43 functions touch the filesystem, 2 make outbound network calls, and 1 runs an external command—this is primarily an API-driven system where most I/O happens through the Ghost content/admin APIs.

How To Use It

# Clone and install
git clone https://github.com/moses-y/Ghost
cd Ghost
pnpm install

# Development
pnpm dev

# Production build
docker build -f Dockerfile.production -t ghost .

Configuration lives in .env.example at the root. The Dockerfile uses node:$NODE_VERSION-bookworm-slim as a base. The README documents the production path: npm install ghost-cli -g then ghost install for server deployment, or ghost install local for local development.

Real-World Use

A publisher deploys Ghost via Docker, uses the admin interface at ghost/admin to write posts, and the portal app handles member signups and subscriptions. The comments-ui app renders comment threads on the public site. Each app is independently deployable and talks to the core Ghost API.

Code Health & Issues

Static analysis found 9 issues (1 critical, 2 high, 5 medium, 1 low):

Critical - Secrets in workflows a fork can trigger - .github/workflows/deploy-to-staging.yml holds CANARY_DOCKER_BUILD with publish/cloud scope; a PR becomes credential exfiltration. Fix: use workflow_run jobs that never check out PR code.
High - Committed .env files - apps/comments-ui/.env, apps/portal/.env, apps/signup-form/.env.development are tracked despite .gitignore rules. These are likely live credentials. Fix: git rm --cached and rotate.
Medium - Unpinned Docker base image in Dockerfile.production; no dependency vulnerability scan in CI; no pre-commit secret gate; persist-credentials: false missing in CI checkout; preinstall lifecycle script in package.json runs on every install.
Low - No timeout-minutes on CI jobs, risking overlapping runs.

The repo has tests (1,764 files), CI via GitHub Actions, a license, and a lockfile. The committed secrets are the most urgent issue—they should be rotated and removed before any public use.

The Bottom Line

Ghost is a mature, well-architected publishing platform with a clean separation between core CMS and frontend apps. The committed .env files and workflow secrets are serious security liabilities that need immediate remediation. For a production deployment, use the official Ghost CLI or Docker image rather than building from this fork until those are resolved.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

6,956 files

JavaScript3106
TSX853
TypeScript790
JSON470
CSS180
Markdown75

ReactFlaskExpressTailwindDockerKubernetes

Findings

LowSecret-shaped paths present; the code-health audit confirms or clears them apps/comments-ui/.env, apps/portal/.env, apps/signup-form/.env.development

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

critical1

high2

medium5

low1

Keep secrets out of workflows a fork can triggercritical

.github/workflows/deploy-to-staging.yml

CANARY_DOCKER_BUILD (publish or cloud scope)

Contributor-controlled input reaches a job holding a publish token or cloud credential, so a pull request becomes credential exfiltration.

Fix: Move secret-using steps into a workflow_run job that never checks out pull request code, or gate on an environment with required reviewers.

Untrack the file your own .gitignore says to ignorehigh

apps/comments-ui/.env

tracked although .gitignore excludes it

The author already decided this file must never be committed, so its presence is an accident nobody noticed, which means the credentials in it are the ones actually in use.

Fix: git rm --cached the path and rotate; the ignore rule is already correct.

Remove the committed .env and rotate what it holdshigh3 occurrences

apps/comments-ui/.env

apps/comments-ui/.env, apps/portal/.env, apps/signup-form/.env.development

A tracked .env is the most common route for a working key to reach a public clone, and it is the file the app actually loads, so the value is usually live.

Fix: git rm --cached the file, add it to .gitignore, rotate every credential it names, commit a .env.example with empty values.

Pin the container base image by digestmedium

Dockerfile.production

node:$NODE_VERSION-bookworm-slim

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Add a pre-commit secret gatemedium

a secret-shaped file is tracked and no repo-level gate is visible

Without a gate the same class of leak recurs on the next commit, so a leak finding is the symptom and this is the cause.

Fix: Add a pre-commit hook scanning staged content, and enable push protection.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Review the install lifecycle script and disable scripts in CImedium

package.json

preinstall

Install scripts are the execution vector for every npm compromise from event-stream onward, and a postinstall that fetches a binary makes the build depend on a URL nobody reviews.

Fix: Move the work into an explicit build step, or set ignore-scripts in CI and run it by name.

Set timeout-minutes on the workflow jobslow3 occurrences

.github/workflows/ci-release.yml

3 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.