flightphp/core: a zero-dependency PHP micro-framework for REST APIs

What flightphp/core actually does

Flight is a router with a small application object attached. The README describes it as "a fast, simple, extensible framework for PHP" that lets you "quickly and easily build RESTful web applications", and states that it has zero dependencies. That last point is the whole pitch. Composer will not drag a PSR container, an event dispatcher and a logging library into your vendor directory just so you can map a URL to a callback.

The audience is narrow and easy to identify. You are building a JSON API, a webhook receiver, a small internal service or a prototype, and you already know PHP. You do not want a framework that dictates directory structure, or one that assumes you will use its ORM. The README points to a separate skeleton app at flightphp/skeleton for people who do want a starting structure, which is a reasonable split: the core stays minimal, the opinionated scaffolding lives elsewhere.

What it is not is a full-stack framework. There is no bundled templating engine, no database layer and no admin generator in the core package. The repository topics list restful and restful-api, which matches the framing. If your project needs a form builder and a migration system out of the box, Flight is the wrong starting point.

Routing, dispatch and the request lifecycle

The mechanism is a route table plus a dispatcher. You register routes against HTTP methods and paths, then hand control to the framework with a single call at the bottom of your entry file. The README's example is the canonical shape: require the autoloader, call Flight::route with a path and a closure, then call Flight::start().

Two details matter for reasoning about behaviour. First, the framework is a front controller. The repository has an index.php at the top level, and the README's sample file is also named index.php, so the intended deployment is a single entry point that every request passes through, with a rewrite rule in the web server sending unmatched paths to it. Second, routing is callback-based rather than controller-class-based by default, which means dispatch is a lookup and an invocation rather than a container resolution. That is where much of the speed claim comes from, and it is also why the README can honestly say there are zero dependencies.

The README does not document the internal dispatch order, how middleware wraps the route callback, or how errors inside a callback are surfaced. Those live on docs.flightphp.com. Treat the README as a quickstart, not a specification. Related searches for "flightphp request" and "flightphp middleware" point at exactly the material the README omits, which is a fair signal that the documentation site, not the repository readme, is where you will spend your reading time.

Installing flightphp/core and serving a first route

Installation is one Composer command. The README gives it directly:

composer require flightphp/core

After that, create an index.php in your project root. The README's basic usage example is this:

require 'flight/autoload.php';

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

Flight::start();

Serve that file with a PHP-capable web server and requesting the root path should return the string hello world!. The README does not give a server invocation, so the deployment detail is yours to fill in; the route path, the closure body, the autoload require and the Flight::start() call are all taken from the README example.

If you prefer not to use Composer, the README states you "can download a zip of this repo", in which case the autoload path in the require line is what makes the example work. The README also mentions the skeleton app at flightphp/skeleton, which is the better starting point if you want a directory layout rather than a single file.

The benchmark chart is not a reason to choose it

The README includes a chart comparing Flight against Yii, Fat-Free, Slim, Phalcon, Symfony, Lumen, Laravel and CodeIgniter, sourced from TechEmpower, with Flight at the top of the bar list. It is worth being blunt about what that chart does and does not tell you. It measures requests per second on a plaintext and a JSON test. It says nothing about database access, template rendering, or how any of these frameworks behave once you add the middleware and service layers a real application needs.

The comparison also flattens architectural differences into one number. Laravel and Symfony ship far more machinery in the request path; a router that invokes a closure has less to do. That is a legitimate design choice, but the chart presents it as a ranking rather than a trade-off. If raw throughput on a trivial endpoint is your deciding factor, you are probably not building the kind of application where framework ergonomics matter, and you should also be looking at whether you need PHP at all.

The honest reading is narrower: Flight does not add meaningful overhead on top of PHP itself. That is a useful property. It is not evidence that Flight will make your application fast, because your application's speed will be dominated by whatever you put inside the route callbacks.

Where Flight stops helping you

The zero-dependency promise has a cost, and the README is quiet about it. There is no documented error handling story in the readme, no session or authentication layer, no validation helper and no database abstraction. Every one of those is a decision you make and a library you choose. That is fine for an API that fronts an existing service layer; it is a poor fit for a team that wants conventions decided for them.

Middleware is the sharpest example. Related searches for "flightphp middleware" suggest people go looking for it immediately, but the README does not describe how middleware is registered or in what order it runs relative to route callbacks. Ordering bugs in middleware chains are subtle and annoying, and if the behaviour is only described on the documentation site, you should read that page before you build a chain of five filters and discover the execution order is not what you assumed.

The other constraint is the PHP floor. The README states plainly that Flight requires PHP 7.4 or greater, and explains the reasoning: PHP 7.4 was still the default on some LTS Linux distributions at the time of writing, and forcing PHP 8 would cause "heartburn" for those users. That is a defensible support decision, and it also means you should not expect the codebase to lean on PHP 8 syntax. If your host is pinned to an older PHP, check the version before anything else; the framework will not run below 7.4.

Flight versus Fat-Free Framework

Fat-Free Framework appears both in the README's benchmark chart and in the related searches, which makes it the natural comparison. The difference is in what ships in the box. Fat-Free is built around a broader toolkit: its own template engine, a database abstraction layer and a routing system, all in one package. Flight keeps the core to routing and a small application object, and expects you to bring the rest.

That changes the shape of a project. With Fat-Free you adopt a set of conventions and get a working application skeleton from the first install. With Flight you make each of those choices yourself, which is more work up front and less work later if you disagree with a framework's opinions. Neither approach is better in the abstract; they suit different teams.

The performance chart in the README places Flight above Fat-Free on the plaintext and JSON tests. Given how much more Fat-Free loads per request, that ordering is unsurprising and should not be read as a general verdict. The real question is whether you want a router or a toolkit. If you already have a service layer, a logger and a template engine you like, Flight composes with them without argument. If you want one package that answers all of those questions, Fat-Free is the closer match.

Maintenance, the v3 line and the MIT licence

The repository is not archived. The most recent push recorded is 2026-09-04, which is the same timestamp as the v3.19.3 release, with v3.19.2 on 2026-09-02 and v3.19.1 on 2026-08-11 before it. That is a steady patch cadence across a few weeks, and the version numbers show a project that has been through many minor releases without a major rewrite.

The README makes the stability intention explicit. It states that upgrading from v2 to v3 should work without issues "depending on how your project was built", points to a migrating-to-v3 page on the documentation site for anything that breaks, and says it is the project's intention "to maintain longterm stability of the project and to not add rewrites with major version changes". For a framework you plan to keep for years, that sentence is more valuable than any benchmark bar.

Upgrade cost is therefore low in the normal case and concentrated in two places: the v2 to v3 migration notes, and the PHP version floor. There is no separate upgrade tooling mentioned in the README. The licence is MIT, which permits commercial and closed-source use and requires only that the copyright notice and permission notice be preserved; the README links to a licence page on the documentation site. That is a permissive arrangement, but it is not legal advice, and if you redistribute the framework inside a product you should confirm the notice requirements with whoever handles licensing at your organisation.

Editorial conclusion

Adopt flightphp/core when you want a minimal PHP router with no dependency tree and you are comfortable reading the documentation site for anything beyond routing. Do not adopt it if you need a full MVC stack with bundled ORM, templating and admin scaffolding, or if you cannot run PHP 7.4 or greater. Before committing, verify two things yourself: the PHP version on your target host, and whether the v2 to v3 migration notes at docs.flightphp.com/learn/migrating-to-v3 mention any API your existing code uses. The repository's last push was on 2026-09-04.

Frequently asked questions

Official sources

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