October CMS 4 requires PHP 8.2 or newer, Composer 2, and a supported SQL database before installation can begin. The cleanest current path is Composer when you control the shell, while the web installer remains available for a simpler browser-driven setup.
For local work, DDEV is the most structured October CMS Docker route because it bundles the web server, PHP, database, and development tooling into a repeatable environment. You can also use Laravel Valet, Laragon, or the built-in Laravel server, but those choices affect convenience more than the application itself.
October is built for projects where a developer owns more of the stack. The October CMS versus WordPress developer trade-off becomes concrete during setup because hosting an October CMS site usually means controlling PHP extensions, database access, file permissions, and deployment rather than relying on a one-click managed path.
With shell access, Composer creates the project, and October's Artisan commands finish the application setup. After composer create-project october/october myoctober, run php artisan october:install to write the configuration, and then php artisan october:migrate to initialize the October CMS database. For quick local testing, php artisan serve can start Laravel's built-in development server.
The browser route uses the October CMS download for the installation wizard instead. Put the installer in an empty writable directory, open install.php, and complete the database and administrator steps in the browser. Once setup finishes, the default October CMS admin panel lives at /admin, which is the normal entry point to the October CMS backend.
Composer and the wizard solve the same basic setup problem but suit different levels of server access. Older October CMS tutorial pages still circulate with obsolete version assumptions and commands, so mixing an old deployment recipe with a current version 4 project can produce errors before your own code is involved.
People coming from hosted builders often underestimate how much infrastructure a self-hosted application exposes. Hosted and self-hosted website building platforms differ most sharply here because October expects you to own the runtime, credentials, filesystem access, and web-server behavior.
The same distinction between version compatibility and real hosting compatibility appears with XenForo shared-host PHP requirements, where extensions and permissions can matter as much as the advertised runtime. For October CMS hosting, verify the actual extensions and filesystem behavior before moving a project onto a cheap shared plan.
An October CMS license is not needed just to explore the software locally, so you can get the application running before tying the project to a paid key. Marketplace access and software updates need that project key later. October CMS plugins can then be added from the project with php artisan plugin:install AuthorName.PluginName.
For a hardened web root, php artisan october:mirror creates a public directory that the web server can expose instead of serving the whole project tree. Re-run the mirror after installing themes or plugins unless automatic mirroring is configured. A Plesk NGINX subdirectory rewrite changes request paths before PHP receives them, so a subfolder deployment deserves its own rewrite and document-root check.
Finish by testing the frontend, the admin area, forms or other interactive components, HTTPS, and the first backup of both files and database. An October CMS update is much less stressful when the production tree can be rebuilt from code and dependencies while the content database and uploaded files are backed up separately. A backup you have never restored is only an assumption, so verify the recovery path before the first risky update.
For local work, DDEV is the most structured October CMS Docker route because it bundles the web server, PHP, database, and development tooling into a repeatable environment. You can also use Laravel Valet, Laragon, or the built-in Laravel server, but those choices affect convenience more than the application itself.
October is built for projects where a developer owns more of the stack. The October CMS versus WordPress developer trade-off becomes concrete during setup because hosting an October CMS site usually means controlling PHP extensions, database access, file permissions, and deployment rather than relying on a one-click managed path.
Choose the install path before touching the server
Start with the October CMS requirements rather than an old hosting tutorial. The current October CMS PHP floor is 8.2, with Composer 2 plus PDO, cURL, OpenSSL, Mbstring, ZipArchive, GD, and SimpleXML required. Version 4 supports MySQL 5.7 or MariaDB 10.2 and newer, PostgreSQL 9.6 or newer, and SQLite 3.8.8 or newer.With shell access, Composer creates the project, and October's Artisan commands finish the application setup. After composer create-project october/october myoctober, run php artisan october:install to write the configuration, and then php artisan october:migrate to initialize the October CMS database. For quick local testing, php artisan serve can start Laravel's built-in development server.
The browser route uses the October CMS download for the installation wizard instead. Put the installer in an empty writable directory, open install.php, and complete the database and administrator steps in the browser. Once setup finishes, the default October CMS admin panel lives at /admin, which is the normal entry point to the October CMS backend.
Composer and the wizard solve the same basic setup problem but suit different levels of server access. Older October CMS tutorial pages still circulate with obsolete version assumptions and commands, so mixing an old deployment recipe with a current version 4 project can produce errors before your own code is involved.
People coming from hosted builders often underestimate how much infrastructure a self-hosted application exposes. Hosted and self-hosted website building platforms differ most sharply here because October expects you to own the runtime, credentials, filesystem access, and web-server behavior.
Server compatibility goes beyond the PHP version
A host advertising PHP 8.2 does not automatically satisfy October CMS permissions or extension requirements. File ownership, writable paths, disabled PHP functions, database access, and Composer availability can still stop an otherwise compatible server, which is why the headline version number is only the first check.The same distinction between version compatibility and real hosting compatibility appears with XenForo shared-host PHP requirements, where extensions and permissions can matter as much as the advertised runtime. For October CMS hosting, verify the actual extensions and filesystem behavior before moving a project onto a cheap shared plan.
An October CMS license is not needed just to explore the software locally, so you can get the application running before tying the project to a paid key. Marketplace access and software updates need that project key later. October CMS plugins can then be added from the project with php artisan plugin:install AuthorName.PluginName.
Production deployment needs a public document root
October CMS deployment should not be treated as copying the local folder to a server and hoping the front controller catches everything. Keep .env out of version control, install production dependencies with composer install --no-dev, configure the production environment, and run php artisan october:migrate so the live database matches the code.For a hardened web root, php artisan october:mirror creates a public directory that the web server can expose instead of serving the whole project tree. Re-run the mirror after installing themes or plugins unless automatic mirroring is configured. A Plesk NGINX subdirectory rewrite changes request paths before PHP receives them, so a subfolder deployment deserves its own rewrite and document-root check.
Finish by testing the frontend, the admin area, forms or other interactive components, HTTPS, and the first backup of both files and database. An October CMS update is much less stressful when the production tree can be rebuilt from code and dependencies while the content database and uploaded files are backed up separately. A backup you have never restored is only an assumption, so verify the recovery path before the first risky update.