Flight: an extensible PHP micro-framework

Sources and evidence limits

The only evidence used is the official Flight repository page, which is treated as reference data. Where it is silent, this guide says unknown.

What Flight is

The repository describes Flight as an extensible micro-framework for PHP. It says Flight is fast, simple and extensible, that it helps you build RESTful web applications, and that it has zero dependencies. Its topics include flightphp, micro-framework, php, restful and restful-api. It is released under the MIT license.

Flight is a framework, a library of code that your PHP application loads. It is not a standalone PHP runtime and it is not a content management system. PHP core is the language engine that executes your files. A framework component or microframework gives you structure on top of that engine. A CMS product such as Drupal CMS is a complete application with content storage, administration and user management. Flight belongs to the first group of tools, not the CMS group. The source mentions no relationship to Swoole, Open Swoole or any other runtime, so this guide does not claim one.

Architecture and execution model

The README shows a deliberately small model. You load the framework, register routes with Flight::route, and call Flight::start(). A route pairs a URL pattern with a callable, and the README's example echoes text from an anonymous function. The README does not describe internals such as the dispatcher, middleware or templating, so this guide does not either. The documentation site named in the README, docs.flightphp.com, is the place to learn those features. It was not part of the supplied evidence.

The documented usage fits the classic request lifetime. A web server starts PHP for a request, your entry script registers routes and starts the framework, a response is produced, and the process state is discarded. Each request starts clean.

Classic requests versus persistent workers

In a persistent worker model, one PHP process stays alive and handles many requests. That can save bootstrap work, but memory is no longer discarded after each response. The source does not say whether Flight supports this mode, so support is unknown.

If you ever run any framework in a persistent worker, plan for state leakage. Leakage means data from one request is visible to a later one. Typical causes are static properties, global variables, singletons, caches, open connections and request or user objects stored in shared places. Flight's public API is called statically, for example Flight::route. Static facades keep state at the process level, so in a long-lived process you must find out whether that state can be reset between requests. The source does not answer this. Cleanup practice generally means:

• Build request-specific data inside the handler and never store it in static or global state.
• Reset or recreate anything tied to a user, session or request before the next request starts.
• Close or validate connections and release temporary resources.
• Test with repeated requests as different users, and watch memory growth.

Until the project's documentation confirms a worker approach, treat classic request-per-process hosting as the only path the evidence supports.

Practical use cases

The README's wording points to small RESTful web applications and APIs, where a route table and a few callables are enough. It also suggests learning how routing and request handling work without a large framework. The README also says the documentation website is itself built with Flight. Whether Flight suits large teams or large codebases is unknown from this source.

Installation approach

The README gives two ways to install: run composer require flightphp/core, or download a zip of the repository. It also mentions a skeleton app at flightphp/skeleton for a fuller starting layout. This guide uses Composer. With a Composer install, the standard vendor/autoload.php file is the natural entry point. The README's flight/autoload.php line applies to the zip download.

Requirements and compatibility

The README says Flight requires PHP 7.4 or greater and that the framework also supports PHP 8. It explains that 7.4 remains supported because some LTS Linux distributions use it by default. It does not name PHP 8.4 or PHP 8.5. Support for those versions is therefore unknown here. Our learning track stays on PHP 8.4 with PHP 8.5 planned, so the example below uses only plain syntax and the two API calls shown in the README. Confirm it on PHP 8.4 during the integration check before relying on it.

The README also mentions upgrading from v2 to v3, says a migration page documents any issues, and says the project intends long-term stability. It states no current version number, so none is given here.

Strengths

• A very small surface: install, define routes, start.
• Zero dependencies, according to the README.
• A permissive MIT license.
• A broad PHP version floor, which helps on older distributions.
• A skeleton app, documentation site, roadmap and community chat, all linked from the README.

Limitations and unknowns

• The README makes speed claims and cites TechEmpower benchmarks. This guide does not repeat or verify them, and your results will depend on your own code and hosting.
• Lifecycle is marked unknown. The page shows repository activity but states no support policy or release status.
• Persistent worker support, PHP 8.4 and 8.5 support, and security-fix windows are not in the evidence.
• Features such as middleware, templating, validation, database access and authentication are not covered by the README. Do not assume a feature exists until you find it in the official documentation.
• A micro-framework leaves most application decisions to you, which means more responsibility for structure and security.

Deployment

The source gives no deployment instructions, so specific guidance is unknown. In general, a classic PHP application is served by a web server that hands requests to PHP, with the entry script in a public directory and dependencies outside it. If you use FastCGI between a web server and PHP-FPM, keep it on a private interface and never expose it publicly. The built-in server in the example is for local development only.

The example

The example creates a Composer project with two routes and serves it from the PHP development server bound to 127.0.0.1. It is a command-line and network-dependent exercise, because Composer downloads the package. It is not a browser exercise. Run it only on a machine where you can install packages.

Where to go next

Read the official repository README, then follow its pointers to the documentation, skeleton app, roadmap and migration notes. Verify any feature you plan to use against those pages.

{
    "name": "learnphponline/flight-hello",
    "description": "Minimal Flight example for a learning guide",
    "type": "project"
}

<?php

declare(strict_types=1);

require __DIR__ . '/../vendor/autoload.php';

Flight::route('/', function () {
    echo 'hello world!';
});

Flight::route('/health', function () {
    echo 'ok';
});

Flight::start();

composer require flightphp/core
php -S 127.0.0.1:8000 -t public public/index.php
curl http://127.0.0.1:8000/
curl http://127.0.0.1:8000/health