October CMS: installation, configuration, and licensing

composer create-project writes into a directory called myoctober

October installs as a Composer project rather than a tarball you unpack. With Composer on the machine, one command lays down the framework into a directory named myoctober:

composer create-project october/october myoctober

That step only creates files. The database is a separate and conditional step, run from inside the new application directory, and only needed if you plan to use one:

php artisan october:install

The version 4 guide also describes database initialization with `php artisan october:migrate`, or on first backend access, and requires a license key to complete installation. Check its PHP extensions and web-server prerequisites before starting. A `.devcontainer/` directory is also available for development.

The install link still points at the 3.x documentation

That guide link deserves a second look before you follow it. The default branch here is 4.x, and the recent tags are v4.2.0 on 2026-03-30, v4.3.0 on 2026-07-19 and v4.4.0 on 2026-08-30. The installation guide the README points you at lives under a 3.x path in the docs tree.

The consequence is that the two commands you were just given and the prose you land on can describe different generations of the platform. For a 4.x installation, use the published version 4 guide at https://docs.octobercms.com/4.x/setup/installation.html and check configuration against your installed version. It includes prerequisites, installation, migration, and production guidance. Release notes sit separately, at octobercms.com/changelog, which is where upgrade expectations for a v4.2 to v4.3 jump belong.

APP_KEY and DB_PASSWORD both ship empty in .env.example

The template environment file is a working starting point rather than a hardened one, and two of its values are blank. APP_KEY= is empty, and the mysql block carries DB_USERNAME=root with an empty DB_PASSWORD= alongside DB_HOST=127.0.0.1 and DB_PORT=3306.

Copy that template to .env and boot the site unchanged and you have a debug-mode application with a known-empty application key and a database account named root. APP_DEBUG=true and APP_ENV=local are development defaults; exposing verbose diagnostics in production can reveal sensitive information, so configure the production environment before deployment. The README does not document a key generation command, so take that from the Laravel documentation October builds on rather than guessing at an artisan argument.

Two more defaults shape behaviour instead of security. QUEUE_CONNECTION=sync runs queued jobs inline during the request that enqueued them, and CACHE_STORE=file with SESSION_DRIVER=file keeps both on local disk, which matters the moment you put a second web server behind the same site.

CMS_ROUTE_CACHE, BACKEND_URI and CMS_SAFE_MODE are October's own keys

Six entries in .env.example belong to October rather than to Laravel, and they are where platform behaviour gets configured. CMS_ROUTE_CACHE=false and CMS_ASSET_CACHE=false both leave caching off; enabling them stops route resolution and asset publishing from redoing work per request. CMS_SAFE_MODE=false and LINK_POLICY=detect are also set in the template.

BACKEND_URI=/admin is the single line that determines where the administration interface lives. BACKEND_TURBO_ROUTER=false is also set in the template.

Permissions get two constants, DEFAULT_FILE_MASK=775 and DEFAULT_FOLDER_MASK=775. LOG_DEPRECATIONS=false keeps deprecation noise out of the single log channel unless you switch it on while chasing a plugin calling an old API.

Both .htaccess and nginx.conf sit at the repository root

October ships rewrite rules for two different web servers at the same level of the repository, an .htaccess file for Apache and an nginx.conf for nginx. You pick one and the other sits there unused, so a deploy written against nginx that assumes Apache rewrite semantics fails on routing rather than on PHP.

Front controller behaviour lives in index.php, and command line work goes through artisan, the Laravel entry point October inherits. Neither file's role inside a server block is explained on the front page, so deployment configuration is something you write yourself from the files themselves. A .devcontainer/ directory supports local work in a defined environment; a production web server recipe is not in the repository. Anyone expecting a CMS to hand over a finished server block will spend real time on this step.

package.json carries two Popper packages and a beta Dropzone

The front end is built with laravel-mix at ^6.0.39, and the npm scripts decide how it runs. npm run dev maps to mix, npm run watch to mix watch, npm run watch-poll polls on a one second interval, npm run hot runs mix watch --hot, and npm run prod goes through npm run production to reach mix --production. Styles compile through less and sass, each listed as a devDependency with a matching loader.

The dependency list is where a version bump bites. Two Popper packages sit side by side: @popperjs/core at ^2.11.7 and the older popper.js at ^1.16.1. dropzone is pinned at ^6.0.0-beta.2, a beta release in the runtime dependencies. Vue is held at ^2.6.14 with vue-router at ^3.5.3, alongside jquery at ^3.6.0 and bootstrap at ^5.3.3.

Nothing explains why both Popper packages are needed. If you plan to write themes against this stack, confirm which one a plugin's JavaScript actually imports before assuming either is removable.

October is source-available under an EULA, not an open source license

October describes itself as a self-hosted CMS platform based on the Laravel PHP framework. Licensing is where the fine print sits: October CMS is source-available software licensed under an End User License Agreement, and that agreement is LICENSE.md at the repository root. Source-available and open source are different claims, and the repository records no asserted license of its own.

If a compliance checklist asks for an OSI-approved license, this project does not satisfy it on its own terms, and the EULA text holds the actual grant and any conditions attached to it. Read LICENSE.md before redistributing, before offering the platform as a managed service to a third party, and before copying it into a client codebase that ships under different terms. That is a licensing question, not legal advice.

Two facts fit here too. October was founded in 2014 by Alexey Bobkov and Sam Georges, and the last push to this repository was on 2026-11-01. Coding standards are pinned to PSR-4, PSR-2 and PSR-1, with phpcs.xml at the root and phpunit.xml beside it.

Editorial conclusion

Adopt October CMS when you want a self-hosted Laravel site with the backend moved off the front path and cache behaviour you control from environment keys, and accept that deployment config and the front end build are yours to finish. Do not adopt it if your compliance process requires an OSI-approved license, since the project is source-available under LICENSE.md. Before anything else, scaffold with composer create-project october/october, then inspect APP_KEY, APP_DEBUG and DB_PASSWORD in your own .env, because the shipped template leaves all three empty or debug-enabled.

Frequently asked questions

Official sources

1. Issues
2. octobercms/october on GitHub
3. Project website
4. README
5. Releases