> ## Content Index
> Fetch the complete content index at: https://discoverghost.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Why Ghost Chose Node.js Over PHP in 2013
- URL: https://discoverghost.com/ghost-nodejs-over-php/
- Published: 2013-05-01T12:00:00.000Z
- Updated: 2026-07-19T21:40:51.000Z
- Description: 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.
- Author: Harish Chouhan
- Tags: Ghost History, #Import 2026-10-22 16:21

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.

![Illustration of PHP and LAMP stack giving way to Node.js powering a modern blog](https://discoverghost.com/content/images/2026/07/ghost-nodejs-over-php-feature.png)

Ghost’s 2013 bet: replace the LAMP-era blogging default with a Node.js publishing core.

## 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](https://discoverghost.com/ghost-0-5-2-release-guide/) when multi-user admin and structured themes arrived.

## Sources and further reading

- [Ghost Kickstarter announcement (2013)](https://john.onolan.org/ghost-just-launched-on-kickstarter/?ref=discoverghost.com)
- [Ghost Developer Docs — Changes](https://docs.ghost.org/changes?ref=discoverghost.com)