Why Ghost Chose Node.js Over PHP in 2013
Ghost launched on Kickstarter in 2013 with Node.js while WordPress still ruled on PHP. Here is why that architectural bet made sense for a modern publishing platform.
When Ghost appeared on Kickstarter in April 2013, the default answer for “I need a blog” was still WordPress on a LAMP stack. Ghost’s founders deliberately went the other way: Node.js on the server, JavaScript end to end, and a codebase small enough that a solo developer could reason about it in an afternoon.
The problem Ghost was solving
WordPress had grown into a general-purpose CMS. That flexibility came with cost—plugin conflicts, security surface area, and admin screens that felt built for 2005 workflows. John O’Nolan’s original concept was narrower: professional publishing with a writing experience that stayed out of the way.
That product goal drove the technology choice. Ghost did not need to run every possible website. It needed to render posts quickly, expose clean APIs, and evolve fast without dragging a decade of PHP compatibility along.
Why Node.js fit the brief
One language across the stack
Node.js let the early team share patterns between server code and the emerging client-side admin. In 2013, JavaScript was already the lingua franca of front-end work. Anchoring the backend in the same language reduced context switching and made it easier for contributors to ship features without maintaining parallel PHP and JS expertise.
Async I/O matched publishing workloads
Blog traffic is spiky: a post hits Hacker News, RSS readers poll feeds, and image assets get requested in bursts. Node’s non-blocking I/O model handled concurrent connections efficiently on modest hardware—important for a project that wanted self-hosting to remain practical.
A modern module ecosystem
npm was maturing quickly. Express gave Ghost a thin, well-understood HTTP layer without imposing a heavyweight framework. SQLite (initially) kept local installs simple—download, run, publish—while leaving room to adopt MySQL later for larger deployments.
What PHP would have implied
PHP was battle-tested for WordPress, Drupal, and countless hosts. Choosing it would have signaled continuity with the incumbent ecosystem—but also inheritance of its architectural baggage: shared-nothing requests, mixed templating conventions, and the expectation that every feature arrive as a plugin.
Ghost’s bet was opinionated core software rather than infinite extensibility on day one. Node.js aligned with building a cohesive product where the editor, theme layer, and API evolved together.
Trade-offs the team accepted
No stack is free. Early Ghost adopters dealt with a smaller hiring pool than PHP in 2013, Node’s relative youth compared to two decades of WordPress hosting guides, and breaking changes as the API and theme system matured through 0.x.
Those costs were visible. The upside was velocity: Ghost could ship JSON APIs, refine admin UX, and iterate on themes without reconciling every decision with a plugin marketplace.
How this decision aged
The Node.js foundation made later milestones easier to explain in hindsight:
- Headless publishing — JSON-first APIs fit naturally on a Node server
- Modern admin — The Koenig editor era built on the same JS toolchain
- Memberships and newsletters — Real-time workflows and integrations mapped cleanly to Node services
Ghost 1.0 and beyond introduced breaking changes, but the core architecture never required a wholesale rewrite away from Node. That continuity matters for teams planning long-term migrations.
Takeaways for publishers and developers
If you are evaluating Ghost today, its Node.js roots show up in practical ways: theme development uses Handlebars with helpers maintained by core, APIs are first-class, and self-hosted installs expect a Node runtime rather than PHP-FPM.
You do not need to love JavaScript to publish on Ghost. You do benefit from understanding that the platform optimizes for a single, modern stack—not maximum plugin compatibility.
For the next chapter in Ghost’s timeline, see the Ghost 0.5.2 release guide when multi-user admin and structured themes arrived.
Discussion