FUEL CMS is a CodeIgniter CMS that has already told you to stop using it

The first line of the README is the whole review

FUEL CMS opens with a warning that is worth reading before anything else on the page. The project is no longer in active development, and it is not recommended for production websites anymore.

That is unusual framing for a README, and it is a deliberate act of disclosure rather than an oversight. A CMS that a team is running quietly, the kind that was chosen years ago and never revisited, is exactly the project where a warning like this either gets read or gets missed. Putting it above the title means it is the first thing anybody lands on.

The dates back it up. The tagged releases are 1.5.2 from 2022-08-15, 1.5.1 from 2021-11-18 and 1.5.0 from 2021-07-02, and the last push to the repository was on 2026-06-01. The repository is not archived, so the code is still reachable, and the last push date shows that somebody is still touching it, but the releases stopped four years ago.

What is left is a well defined situation: an existing CodeIgniter application with a documented upgrade path and no new development behind it. That is a different proposition from a project that is merely quiet, and it deserves a different evaluation.

Installing it means copying a folder and opening index.php

The installation section is short enough to reproduce from memory, which is a good sign for a system that has been around long enough to be stable.

To install FUEL CMS you copy the contents of the folder to a web accessible folder and browse to the index.php file. Then you follow the directions on the screen. There is no composer step, no build, and no package manager involved. The top level listing matches that description closely, with an index.php, a .htaccess file, a robots.txt file, an assets/ directory and a fuel/ directory.

The index.php and the .htaccess go together, and the presence of the .htaccess file in the repository root is the sign of a PHP application that expects to be served by Apache with a rewrite rule in place. The fuel/ directory is the application itself, and the README points to fuel/licenses/fuel_license.txt for the licence text, so the directory carries the project structure rather than just configuration.

The consequence for a modern team is that there is no dependency resolution to reason about. Whatever PHP and web server the organisation already runs is what runs this, and the upgrade story is about code changes rather than about package versions, which is unusual in 2026 and simplifies one class of risk while raising another.

The 1.4 upgrade changed how controllers and models are named

The upgrade section is the most technical part of the documentation, and it is where a FUEL CMS owner will actually spend time.

The note says that FUEL 1.4 uses CodeIgniter 3.x, which includes a number of changes, and that the most prominent of them is the capitalization of controller and model names. In other words, the class names in your controllers and models changed case, and any code that references them by string, by route, or by a filename assumption has to change with them.

The second change is that CodeIgniter 3.x is more strict on reporting errors. That is the kind of change that surfaces existing sloppiness rather than causing it, so the upgrade will find things in the code that were previously tolerated, and the work is proportional to how carefully the site was written years ago.

Both changes are the sort of thing that breaks quietly. A controller that is no longer found returns a 404 rather than a stack trace, and a strict error policy can turn a warning in a log into a visible failure. This is why the documentation recommends testing the upgrade on a different branch first, and why an evaluation of this project has to treat the upgrade path as the main deliverable rather than as an afterthought.

One command automates most of the upgrade

For the mechanical part of the migration, the project ships a script that it says helps automate most, and possibly all, of the updates that may be required in your own fuel/application directory and in your installed advanced module code.

The command is run from the command line.

php index.php fuel/installer/update

Two things in that command line matter. The first is that it is a PHP script executed through the PHP binary, not a web request, so it runs with the same interpreter your site uses. The second is the path, fuel/installer/update, which places the installer inside the application directory, and the instruction to run it using a different branch, which is the same advice you would give for any database-touching migration.

The documentation is careful about the scope of the claim. Most, and maybe all. The word maybe is doing real work, and the honest reading is that the script handles the changes the maintainers anticipated, and that anything in custom code or third party modules still needs a human to check.

So the realistic upgrade plan is: branch, run the command, diff the result, then exercise the site. The script is the first step, not the whole procedure.

Licence, attribution and where the project came from

FUEL CMS is licensed under Apache 2, and the full text of the licence is in the fuel/licenses/fuel_license.txt file inside the application directory. That is the permissive licence with the patent grant, and it permits use, modification and redistribution, including in commercial and closed source products, subject to the attribution requirements.

The repository listing does not include a top level LICENSE file, and no standard licence identifier is attached to the project, so a tooling based check will come back empty. The authoritative text is the file the README points at, inside the application directory, and a compliance scan has to be told to look there.

The project is developed by David McReynolds, of Daylight Studio, and the site is getfuelcms.com with documentation at docs.getfuelcms.com. The bug reporting route is the GitHub issues page rather than a mailing list or a support portal, and the repository also carries a SECURITY.md file, which is the place to look for how to report a vulnerability in an unmaintained system with an exposed web surface.

The absence of a support contract is the other half of the licensing question. Apache 2 tells you what you may do with the code. It does not tell you who will fix a bug you find, and for a system that is no longer in development, that gap is the thing to plan around.

When a sunset CMS is still the right answer

There is a real case for using this project, and it is not a bad one. It is the case of a site that already runs it.

A business with a FUEL CMS installation has a working editorial workflow, a set of trained editors, templates, and content that is structured in a particular way. Replacing it means a migration, a new editorial interface, retraining and a period where publishing is blocked. If the site is low traffic, the feature set is enough and the CMS is not the bottleneck, then the rational move is often to keep what you have and keep it running.

The decision then becomes an operations question rather than an evaluation question. Does the hosting environment still run the PHP version this code expects? Is there a web application firewall in front of it? Are the credentials still rotated? Those are the questions that decide whether a site that stopped receiving feature work is still a safe place to publish.

For a new project, the calculus is different and much simpler. The project tells you not to use it for production websites, and the alternatives are the newer CodeIgniter releases with a maintained ecosystem, or a different CMS entirely. Starting something new on a platform whose own maintainers recommend against it is a decision that has to be made deliberately, and for most teams it should not be made at all.

A repository that is still reachable, and what that means

The repository is not archived, and the last push was on 2026-06-01, several months before this review. That combination, code still reachable and no new releases, is the state most people will meet when they search for this project.

What it means practically is that there is no supported upgrade path beyond 1.5.2. If your site is on an earlier version, the documented route is the 1.4 upgrade procedure, which brings the capitalisation and error reporting changes, and then the patch releases after that. If your site is already on 1.5.2, there is nothing to upgrade to, only to patch and to maintain.

The other consequence is a supply chain question. A PHP application that depends on a framework, with no new releases and an installation that is copied into a web root rather than resolved from a package registry, is harder to keep patched. A site running this today is running the exact code that was published in 2022, plus whatever the site owner changed, plus whatever patches were applied locally.

The security files in the repository are the place to check first. A SECURITY.md in an unmaintained project tells you whether there is a process for reporting a problem, and it is the only signal in the tree about how the code is being looked after now that the feature work has stopped.

Editorial conclusion

Adopt FUEL CMS only for a site that already runs it and needs the 1.4 upgrade path applied carefully, since the update command and the capitalisation change to controllers and models are documented and testable. Do not adopt it for anything new, because the project itself says it is no longer in active development and is not recommended for production websites, and the last tagged release predates the current CodeIgniter generation. Verify first which CodeIgniter version your installation targets, since FUEL 1.4 moved to CodeIgniter 3.x, and read fuel/licenses/fuel_license.txt for the Apache 2 terms before you redistribute the code.

Frequently asked questions

Official sources

1. daylightstudio/FUEL-CMS on GitHub
2. Issues
3. Project website
4. README
5. Releases