October CMS

Last reviewed Aug 26, 2026 · 803 words

October CMS changed its business model in March 2021, and that single fact decides whether it belongs on your server. Version 1 shipped under MIT and built a following among Laravel developers for its flat-file themes and clean plugin API. From version 2 onward the project moved to a paid per-project licence, sold through its own marketplace, and the MIT lineage continued as the community fork Winter CMS. So the honest reading of the catalogue entry is: the MIT code is real and still usable, the current October releases are commercial, and a self-hoster picks between paying for October or running Winter for free. Both are very good if you already think in Laravel; neither is a WordPress replacement for someone who wants to install a theme and start typing.

The theme model is the reason developers like it

An October theme is a directory of files, not a database of settings. A page is a single .htm file with three sections separated by ==: an INI block with the URL and layout, an optional PHP block for page logic, and Twig markup:

url = "/blog/:slug"
layout = "default"
[blogPost]
slug = "{{ :slug }}"
==
function onEnd() { $this['title'] = $this['post']->title; }
==
{% component 'blogPost' %}

Layouts, partials and content blocks follow the same pattern, and components from plugins attach to pages by name. The consequence is that a site lives in Git as files a developer can diff and review, and a git pull on the server is a deploy. Content editors get a clean backend at /backend for posts, media and settings without touching those files. Compared with WordPress, where the theme, the plugins and half the configuration live in the database, this is the "simple, transparent architecture" the catalogue credits it with, and it is why agencies that already run Laravel apps reach for it.

The install is standard PHP hosting

October needs PHP 8.x with the usual Laravel extensions, a database (MySQL, MariaDB, PostgreSQL or SQLite for small sites) and Composer. The tooling is artisan:

composer create-project october/october my-site
cd my-site
php artisan october:install
php artisan october:update

The installer asks for the licence key, database details and the first admin user. Serve public/ from Nginx or Caddy with PHP-FPM, run php artisan schedule:run from cron every minute for queued mail and scheduled content, and cache aggressively; a Twig-rendered page with the built-in cache is fast on 512 MB. Docker images come from the community rather than the project, so most people build a small image from php:8-fpm plus Composer, which is a 20-line Dockerfile. Backups are the database plus the themes/, plugins/ and storage/ directories.

Plugins: a marketplace with prices

The marketplace is where the paid model shows. Core plugins (Blog, Pages, Builder) are free and maintained by the project; a good number of third-party ones carry a one-off price, from a few dollars to around a hundred for e-commerce add-ons at last check. That is not unreasonable for a professional site, but it is a different culture from WordPress's free-first repository, and it is the catalogue's "some plugins are paid" con. Anything you need that does not exist is a plugin you write in Laravel, which for the target user is a feature rather than a chore.

Where Winter, Statamic and WordPress fit

Winter CMS is the fork: same theme model, same plugin API, MIT licence, community-run, and compatible with most October v1 plugins. If the licence cost or the dependency on one company bothers you, that is the answer, and for a hobby or nonprofit site it is my default. Statamic is the other Laravel CMS, flat-file by default, free for personal use and paid for commercial projects, with a more editor-focused control panel; it competes with October for the same developers and wins on the editing experience. WordPress wins for the non-developer and for the client who wants to buy a theme, install 15 plugins and never see a terminal; the CMS category guide covers that split in more depth, and the licence explainer is useful reading before committing a client site to a commercial licence.

What I'd do

For a Laravel developer building a client site with a budget, October: buy the project licence, keep the theme in Git, deploy with a pull and php artisan october:migrate, and treat plugins as a make-or-buy decision per feature. For the same developer building something personal, or for anyone who wants the architecture without the invoice, Winter CMS, which is what I would install today. For a non-developer, neither; go to WordPress and spend the saved hours on content.