bluf:
\nrequire dirname(__DIR__) . '/vendor/autoload.php';\n\nuse Project\\Bootstrap\\ContainerFactory;\nuse Project\\Presentation\\Http\\HttpFrontController;\n\nnew ContainerFactory()\n ->newContainer()\n ->getService(HttpFrontController::class)\n ->run();\nMost PHP systems these days have a bootstrap script (index.php for the web, or console.php for the command line). I've had to review a lot of these as part of my legacy modernization work.
The following survey of public PHP frameworks should give you a good idea of the wide range of design choices made by different bootstrap authors:
\nweb/index.php\npublic/index.php\nwebroot/index.php\nindex.php\nindex.php\npublic/index.php points to app/config/bootstrap.php\npublic/index.php\nindex.php points to includes/app.php\nindex.php\npublic/index.php\npublic/index.php\npublic/index.php\npublic/index.php\nwebroot/index.php\npublic/index.php\nwww/index.php\npublic/index.php\nweb/index.php\npublic/index.php points to a runtime template\npublic/index.php\npublic/index.php\nEach of the bootstrap scripts performs at least a few of the following tasks, though not all of them perform all of the tasks, and none of them necessarily in this order:
\nini_set(), error_reporting(), etc.require framework-specific library filesexit()\nOften enough, one or more of the above tasks is accomplished by including another script from the bootstrap. The CodeIgniter and Joomla bootstrap scripts are typical examples of that. They are a lot like what I see from many in-house PHP bootstrap scripts.
\nLooking again at that list of tasks above, is there a way to consolidate some\nof them into more appropriate locations and maybe even describe a common\napproach to bootstrap scripts?
\nFirst, they could use autoloading exclusively, instead of using require to bring\nin other scripts. That gets rid of:
Next, given the existence of a service container, all configuration tasks could\nbe encapsulated by configuration objects in (or service providers to) that\ncontainer. Doing so would consolidate these tasks, moving the relevant logic out of\nscripts and into more-easily-tested units:
\nini_set(), error_reporting(), etc.After that, request and response work can be moved into the front controller\nitself, removing these tasks from the bootstrap:
\nThat leaves only these remaining tasks:
\nexit()\nThese look like reasonable concerns for a bootstrap script.
\nAre there any bootstrap scripts that already work that way, or close to it? Yes:
\nThese almost work that way ...
\n... but otherwise limit themselves to the reduced set of bootstrap tasks.
\nAt this point, it looks like the major source of variation is how the bootstrap\nscripts obtain and run the front controller (usually called an Application or a\nKernel) :
\n// Aura\n$kernel = (new \\Aura\\Project_Kernel\\Factory)->newKernel(...);\n$kernel();\n\n// Laminas-MVC\n$container = require __DIR__ . '/../config/container.php';\n$app = $container->get('Application');\n\n// Laravel\n$app = require_once __DIR__.'/../bootstrap/app.php';\n$app->handleRequest(Request::capture());\n\n// Mezzio\n$app = $container->get(Application::class);\n$app->run();\n\n// Nette\n$application = $container->getByType(Application::class);\n$application->run();\n\n// PHPixie\n$pixie = new \\App\\Pixie()->bootstrap($root);\n$pixie->bootstrap($root)->http_request()->execute();\n\n// Tempest\nHttpApplication::boot(...)->run();\n\n// Yii\n$runner = new HttpApplicationRunner(...);\n$runner->run();\nOn examination, we find three kinds of relationships between the front\ncontroller (Application) and the service Container:
\nCombined: the Application extends the Container.
\nService-located: the Container is created, then passed into the\nApplication so the Application can locate services; alternatively, the\nApplication itself creates and retains the Container.
\nDependency-injected: the Container is created, then the Application\nis obtained from it.
\nAll of the above variations look like they could be easily reconciled to use a\nfactory to create a service container, then obtain a front controller\nfrom the service container and run it.
\nWith that one final adjustment toward a factory and dependency injection, we\nfind a prototypical set of bootstrap tasks:
\nThis set of tasks should be achievable with little effort in any PHP system.\nHere is an example with hypothetical implementations of the Star-Interop\nstandard interfaces for IocContainerFactory, IocContainer, and FrontController ...
\nrequire dirname(__DIR__) . '/vendor/autoload.php';\n\nuse Project\\Bootstrap\\ContainerFactory;\nuse Project\\Presentation\\Http\\HttpFrontController;\n\nnew ContainerFactory()\n ->newContainer()\n ->getService(HttpFrontController::class)\n ->run();\n... but of course using the Star-Interop standards is not a requirement. Any PHP\nsystem with an autoloader, container factory, service container, and front\ncontroller can follow this idiom.
\nThere are still three activities from the researched bootstrap scripts that are\nnot covered by the prototype ...
\nexit()\n... and those could reasonably be added to the bootstrap code. However, all\nother bootstrap script activity has been consolidated into the container\nfactory, container, or front controller.
\nThis approach also lends itself to command-line systems; we need only to swap\nthe HTTP front controller for a CLI front controller and add an exit():
exit(\n new ContainerFactory()\n ->newContainer()\n ->getService(CliFrontController::class)\n ->run()\n);\nIn conclusion, the prototypical design ...
\nIn short, it standardizes a common approach to bootstrap scripts that is useful to, and recognizable in, any PHP system.
\nMon 09 Feb 2026:
\nAn earlier version of this article linked to the Slim skeleton; per\ncommenter equilini on Reddit\nit now links to the Slim documentation.
Likewise, commenter dknx01 claimed confusion regarding Joomla and Symfony links to the bootstrap scripts; those links have been made more explicit, along with the one for FlightPHP.