CodeIgniter 4: a full-stack PHP framework with an opinionated repository

What version 4 actually is, and what this repository holds

The README is explicit that this repository holds the source code for CodeIgniter 4 only. Version 4 is described as a complete rewrite to bring the quality and the code into a more modern version, while still keeping as many of the things intact that had made people like the framework over the years. The project describes itself as a PHP full-stack web framework that is light, fast, flexible and secure, and points at codeigniter.com for everything else. The description also records its origin as originally from EllisLab, which is history rather than anything you need to know to use it.

The rewrite has a consequence that shows up in the tree. Some components that were part of CodeIgniter 3 are being moved to optional packages with their own repositories, so the feature set of a fresh install today is not identical to what version 3 shipped. That is worth understanding before comparing old tutorials against a new project, and the README flags it as an ongoing process rather than a finished migration.

The default branch is `develop`, and releases are cut from it: 4.7.2 on 2026-03-24, 4.7.3 on 2026-05-22 and 4.7.4 on 2026-07-07. The release notes for each one point at `CHANGELOG.md` on the develop branch and at a compare link, and there is a separate `changelogs/` directory in the tree. The license is MIT, which is the least restrictive thing you could hope for in a PHP framework and removes the usual question about whether you can vendor it.

Why index.php moved into the public folder

The README devotes a section to a single change that tells you a lot about how the project thinks. `index.php` is no longer in the root of the project, and has been moved inside the `public` folder, described as being for better security and separation of components.

The instructions that follow are unusually blunt about the two possible configurations. You should configure your web server to point to the project's `public` folder, not to the project root, and a better practice is to configure a virtual host to point there. A poor practice, in the README's words, is to point the web server at the project root and expect to enter `public/...`, because the rest of the logic and the framework are then exposed over HTTP. That is the whole argument for the layout: the framework in `system/`, your application code in `app/`, generated files and caches in `writable/`, and one directory that is safe to make the document root.

For anyone migrating from CodeIgniter 3 this is the first thing that will break, and the fix is a server configuration change rather than a code change. The README's advice is to read the user guide for a fuller explanation of how CI4 works, which is a reasonable place to stop for detail.

The four directories a project actually uses

The tree is dominated by the framework's own structure, and four entries carry most of the meaning for a person building an application: `app/`, `system/`, `public/` and `writable/`.

app/
system/
public/
writable/

`system/` is the framework, which is why it is worth pointing out that `app/` exists at all. In a standard CodeIgniter 4 project the application directories are created inside `app/` and the framework stays in `system/`, so upgrading the framework does not mean rewriting your own code. `writable/` is where the framework needs permission to put things at runtime. The repository also contains `admin/`, `spark`, `utils/`, `tests/` and `user_guide_src/`, which are development-side directories rather than parts of your deployed project.

The tooling configuration is unusually visible for a PHP framework, and it is all at the repository root. There is `composer.json`, `phpunit.dist.xml` for tests, `phpstan.dist.neon` and `psalm.xml` with a `psalm-baseline.xml` alongside, `rector.php` for automated refactoring, and four separate PHP CS Fixer configurations distinguished by suffix: a default one, one without a header, one for tests and one for the user guide. That last detail is a small signal about how seriously the style of each area is taken.

Where to ask what, and why a pull request is not a feature request

The repository management section is the part of this README that most changes how you would work with the project, so it is worth reading closely. CodeIgniter is developed completely on a volunteer basis, and the project asks you to give up to 7 days for issues to be reviewed, leaving a comment if you have not heard from the team in that period.

Then it splits the channels. GitHub issues are used to track bugs and to track approved development work packages. The forum at forum.codeigniter.com is used for support and to discuss feature requests. If you raise an issue that pertains to support or a feature request, it will be closed. If you are not sure you have found a bug, the advice is to raise a thread on the forum first, because someone else may have encountered the same thing.

The same logic governs contributions. Pull requests are for contributions, specifically ones that address a reported bug or an approved work package, and a pull request should not be used as a form of feature request. Unsolicited contributions will only be considered if they fit nicely into the framework roadmap. There is also a note to check that a bug has not already been reported or fixed before opening a new issue. Whether or not you agree with that division, it is unambiguous, and it tells you that the maintainers' time is the scarce resource rather than the codebase.

PHP 8.2 and the extensions the framework expects

The server requirements are short and current. PHP version 8.2 or higher is required, with `intl` and `mbstring` installed. Four more extensions should be enabled: `json`, which is enabled by default and should not be turned off, `mysqlnd` if you plan to use MySQL, and `libcurl` if you plan to use the HTTP CURLRequest library.

The README also lists end-of-life dates, and they are the reason for the 8.2 floor. PHP 7.4 reached end of life on November 28, 2022, PHP 8.0 on November 26, 2023 and PHP 8.1 on December 31, 2025. The README states that if you are still using a version below 8.2 you should upgrade immediately, and notes that the end of life date for PHP 8.2 will be December 31, 2026. That last line is a genuine deadline for anyone starting on the current minimum: the floor the framework sets now expires at the end of 2026.

Nothing here is unusual for a modern PHP project, and it is worth saying plainly that the requirements are the easy part of the evaluation. The harder question for a team is what happens to your code when the floor moves again, and the repository does not document a deprecation policy for PHP versions beyond stating the current minimum and the published end-of-life dates.

Documentation that admits it is unfinished

Three documentation sources are named, and the third one comes with a warning attached. The user guide at codeigniter.com is the primary documentation for CodeIgniter 4. Alongside it there is a current in-progress user guide, hosted separately, described as a work in progress that will see changes over time to structure and explanations. There is also API documentation for the framework components.

That honesty is a small quality signal. Publishing a second, unstable copy of the guide means the maintainers are willing to show work in progress rather than let the current docs drift silently, and it also means you need to know which one you are reading before you copy code out of it.

Inside the repository, the documentation has its own tooling. The `user_guide_src/` directory holds the sources for the guide, `phpdoc.dist.xml` is the configuration for API documentation generation, and `.php-cs-fixer.user-guide.php` is a separate style configuration for that content, which is the reason there are four fixer configs rather than one. `CONTRIBUTING.md`, `contributing/README.md`, `CODE_OF_CONDUCT.md`, `SECURITY.md` and an `AGENTS.md` sit at the root, and the README points contributors at `contributing/README.md` first. Running the test suite is documented in a separate `tests/README.md` rather than in the main README.

Editorial conclusion

CodeIgniter 4 is a full rewrite that kept the parts of version 3 people relied on, and the repository is more opinionated about process than about architecture. That is the finding here. The framework itself asks for little: PHP 8.2 or higher, two required extensions, a `public/` folder as the only web-exposed path, and a directory layout that separates the framework in `system/` from your application in `app/` and writable state in `writable/`. What takes reading is the contribution model, which splits bugs, support and feature requests across two different places and tells you plainly that an unsolicited pull request will only be considered if it fits the roadmap. For a team picking a framework, that tells you something about how the project will handle your bug reports. Release 4.7.4 shipped on 2026-07-07, 4.7.3 on 2026-05-22 and 4.7.2 on 2026-03-24, and the last push was on 2026-09-22. Start with the user guide at codeigniter.com, then read `contributing/README.md` before opening anything on the tracker.

Frequently asked questions

Official sources

1. codeigniter4/CodeIgniter4 on GitHub
2. License: MIT
3. Project website
4. README
5. Releases