Less runtime. Less memory. Smaller servers. Lower bills.
Justflows carries a fraction of the footprint of a PHP CMS — and it is still the most extensive platform you can self-host for free. Here is exactly where the difference comes from, and what it is worth to you.
Where the difference comes from
The same page, two very different amounts of work
None of this is a micro-optimisation. It is the difference between rebuilding an entire application on every request and simply keeping one running.
A PHP request
Repeats every request- 1nginx hands the request to a PHP-FPM worker
- 2The worker starts a fresh application context
- 3Hundreds of PHP files are parsed and autoloaded
- 4Every active plugin registers itself again
- 5The theme and its hooks are bootstrapped
- 6Only now does the page actually get rendered
- 7The context is torn down and thrown away
Steps 2 to 5 repeat the same work on every single hit, then discard it.
A Justflows request
Warm process- 1The request reaches the already-running process
- 2Cached pages return straight away — no database, no render
- 3Otherwise the router resolves content and renders the blocks
- 4The response goes out; the process stays warm for the next one
Plugins, theme and routes were registered once, at boot. Nothing gets rebuilt.
Footprint
Lighter than PHP — by architecture, not by trick
Justflows does less work per request because it does not throw its application away after each one. That single design choice is where the memory, the latency and the hosting bill all go.
The app boots once, not once per request
A PHP CMS rebuilds itself on every hit: parse the files, autoload the classes, register every plugin, render, tear it all down. Justflows boots once and stays warm, so a request only does the work that request actually needs.
One event loop instead of a worker pool
PHP-FPM reserves a whole process per concurrent request, and each one holds its own copy of the runtime in memory. Node serves thousands of concurrent connections from a single process, so your RAM stops scaling with your traffic.
Caching and static output are in the core
Page cache, object cache and static rendering ship with the platform — no stack of caching plugins to install, tune and keep in sync. Most requests never reach the database at all.
Every PHP-FPM worker carries its own interpreter, its own opcode cache slice and its own loaded extensions. That is why a PHP CMS needs memory in proportion to peak concurrency — and why Justflows does not.
Same box, same page
- Memory, idle
- 3.5× lower
- Memory, under load
- 4.3× lower
- Time to first byte
- 22× lower
- Requests per second
- 19× higher
How this was measured
- 1 vCPU · 1 GB RAM VPS
- Justflows (Node.js 22, built-in cache, PostgreSQL 16)
- WordPress 6.x (PHP 8.3-FPM + nginx + MySQL 8, default theme, no page-cache plugin)
- k6 · 50 virtual users · 60 s · homepage
Reference figures, not a marketing benchmark. Same VPS, same page, no page-cache plugin on the WordPress side — add one and PHP closes much of the latency gap, though not the memory gap. Every figure lives in a single file in this repository. Reproduce the run and send a pull request if you measure something different.
What it costs to run
Pick your traffic. Watch the bill shrink.
Same site, same visitors, two runtimes. The lighter one fits on a smaller box — and a smaller box costs less every month, for as long as the site is up.
1 vCPU · 1 GB
2 vCPU · 4 GB
Estimates, based on typical VPS list prices and the memory footprint above. Your real numbers depend on your host, your traffic shape and how many plugins you run — but the direction does not change: a smaller runtime needs a smaller server.
Full comparison
Every capability, side by side
The free, self-hosted edition of each platform — no enterprise add-ons counted.
Swipe the table sideways to see every platform.
| Capability | Justflows | WordPress | Strapi | Ghost | Payload |
|---|---|---|---|---|---|
| Complete website out of the box | Included, free | Included, free | Not available | Partial or plugin-dependent | Not available |
| Headless content API with a typed SDK | Included, free | Partial or plugin-dependent | Included, free | Partial or plugin-dependent | Included, free |
| Browser install wizard, no terminal | Included, free | Included, free | Not available | Not available | Not available |
| Plugin system with hooks and filters | Included, free | Included, free | Partial or plugin-dependent | Not available | Partial or plugin-dependent |
| Themes and template hierarchy | Included, free | Included, free | Not available | Included, free | Not available |
| Visual block editor | Included, free | Included, free | Partial or plugin-dependent | Partial or plugin-dependent | Partial or plugin-dependent |
| End-to-end TypeScript types | Included, free | Not available | Partial or plugin-dependent | Not available | Included, free |
| Multilingual content and admin | Included, free | Partial or plugin-dependent | Paid tier only | Not available | Included, free |
| Roles and granular capabilities | Included, free | Included, free | Paid tier only | Partial or plugin-dependent | Included, free |
| WordPress importer | Included, free | Included, free | Not available | Partial or plugin-dependent | Not available |
| No capability behind a paid tier | Included, free | Included, free | Not available | Included, free | Included, free |
Reflects the free, self-hostable edition of each project. These projects move fast, and we would rather be accurate than flattering — if a row is out of date, open an issue and we will correct it.
Ready to flow?
Join the open-source community building the future of content platforms.