OpenFlights: flight maps, route data, and installation

What OpenFlights records and displays

OpenFlights addresses two related needs: maintaining a personal record of flights and presenting aviation information through a searchable website. Its documented functions include mapping flights on a zoomable world map, searching and filtering flight records, calculating statistics, and sharing trips with other people. The site is aimed at travelers who want a flight log, aviation data users, and developers looking for free airport, airline, and route records.

The repository separates those uses somewhat awkwardly. The public website is the complete application, while the `data/` directory provides direct access to data and `data.php` points readers toward its documentation and downloadable files. This distinction matters for adoption. A developer who only needs airport coordinates, airline records, or route data may not need to run the PHP application or its MySQL database. A user who wants interactive maps, filters, statistics, and sharing must operate the full site.

OpenFlights is not presented as a realtime aircraft-tracking system. The repository describes stored flight information, routes, and mapping. It also includes `openapi.yaml`, which indicates an API definition exists, but the README does not explain its endpoints, authentication rules, coverage, or update process. Any decision to build automation around that file would require inspecting those details directly.

OpenFlights' browser, PHP, Nginx, and MySQL path

The documented architecture is a classic LNMP application. Most browser-side behavior resides in the monolithic `openflights.js`, with additional scripts under `js/`. That frontend communicates with PHP code under `php/`, which in turn wraps a MySQL database. Nginx serves as the web server. This is a conventional request-and-database architecture, although the project does not provide a more detailed sequence diagram in the README.

The large JavaScript entry point should be considered an adoption constraint. The maintainers describe the codebase as a mess and say that much of it was written in 2008, with tests and package management added later as incomplete additions. A modification to map behavior, filtering, or statistics may therefore cross the boundary between `openflights.js`, PHP handlers, and SQL-backed data.

Development configuration is split across PHP, Nginx, and Composer. The `locale/` directory handles supported languages and translation editing. Tests are divided between client-side full-stack tests, server-side PHP integration tests, and client-side JavaScript unit tests. Both integration groups require a live database, and the full-stack client tests also require a server. That split means the least demanding test category does not provide an isolated substitute for checking database-backed behavior.

OpenFlights Docker setup and first site visit

The README calls the Docker configuration basic and says that several manual steps remain. First, copy the sample PHP configuration into the working configuration file. This command must be run before starting the containers:

cp php/config.sample.php php/config.php

Then edit `php/config.php` and set `$host = "db";`, as specified in the README, so the PHP service resolves the database container. The host port for MySQL is mapped to `3306`, while the web service maps `8007` to Nginx on port `80`.

After the configuration change, the documented startup command creates the database and PHP containers:

docker-compose up

The database container uses `mysql:8.0`. On first initialization, the Compose configuration mounts `sql/create.sql` and `sql/docker-seed.sh` under `/docker-entrypoint-initdb.d/`, which provides a repository-defined database setup path. The README does not describe what records the seed script creates, so its data coverage cannot be determined from the file names alone.

PHP dependencies are installed inside the web container. The documented sequence enters an interactive shell:

docker exec -it openflights-web-1 bash

Inside that shell, change to the mounted application directory and run Composer:

cd /var/www/openflights/ && php /usr/local/bin/composer install

After these steps, the README says the site should be available on port `8007`. A first useful check is therefore to open `http://localhost:8007` and confirm that the browser can reach the Nginx-served PHP application. The site home is the place to exercise flight mapping and search. For a data-only first use, start instead with the files in `data/` and their documentation at `http://openflights.org/data.php`.

OpenFlights data access versus running the application

Running Docker is not the only meaningful form of adoption. The README specifically directs most visitors to the free airport, airline, and route data before discussing the application code. Developers can inspect the direct data files in `data/`, while the online data page documents their availability. This is likely the lower-maintenance path when the requirement is ingestion, analysis, or display in another system.

The trade-off is functionality. Direct files do not automatically provide OpenFlights' map interface, filtering controls, automatically calculated user statistics, or flight-sharing features. The full application adds PHP, Nginx, MySQL, browser JavaScript, configuration, and dependencies around those records. Each layer increases the number of moving parts that must be maintained.

The repository contains SQL files, PHP configuration, OpenAPI material, and deployment configuration, but the README does not state a schema update policy, data refresh interval, canonical import procedure, or backward-compatibility policy for the direct data files. It also does not promise completeness or freshness. Consumers that require predictable refreshes should inspect `sql/`, `data.php`, and the published data documentation before choosing a synchronization strategy.

Testing and maintenance limits in OpenFlights

The repository's own warning about incomplete testing is the main operational limitation. The client full-stack tests require both a live database and server, server integration tests require a live database, and client unit tests cover JavaScript. This makes it possible to work across several testing modes, but it does not provide a clean, isolated default verification path for database-backed changes.

The last push recorded for the repository was on 2026-10-14. That is recent activity, although the project has no GitHub releases. The activity date therefore does not translate into a documented release train or a dependable upgrade path. There are no release notes available to establish migration requirements or compatibility changes.

The Docker image also exposes explicit version choices. It uses `ubuntu:22.04`, installs `php7.4`, `php7.4-fpm` and related PHP 7.4 modules, and starts both PHP-FPM and Nginx through the container command. The README does not discuss whether a newer PHP runtime is supported. Before changing runtime versions, operators would need to validate the application and tests themselves because compatibility is not established by the project documentation.

For dependency work, `composer.json` and `composer.lock` exist, but the README still instructs developers to run `composer install` manually inside the container. The npm side is small in `package.json`: it defines Prettier commands rather than the complete application toolchain. The repository describes package management itself as an incomplete afterthought, which is a warning for contributors and deployment maintainers.

OpenFlights licensing and a different integration approach

OpenFlights is distributed under `AGPL-3.0`. That identifier matters when deciding whether to modify, host, or redistribute the application because the license contains terms for covered software. The repository does not replace the license text, and this review does not interpret individual obligations. Teams using the code should read `LICENSE` and assess how their deployment and distribution plans relate to its requirements.

A real alternative is to consume the airport, airline, and route files directly and render them in a separate application. This approach avoids running OpenFlights' PHP, Nginx, MySQL, JavaScript, and Composer environment when the requirement is limited to aviation reference data or route visualization. The trade-off is loss of the site's existing map, flight filtering, statistics, and sharing behavior unless those features are rebuilt.

Another alternative is to adopt the full OpenFlights site and leave its current feature set intact. That preserves the documented product experience but transfers responsibility for the legacy stack, test setup, database initialization, configuration, and runtime compatibility to the adopting team. The choice is therefore between operating OpenFlights as an application or treating its data files as an input to a smaller custom service.

Editorial conclusion

OpenFlights fits developers who want to operate a feature-rich flight map, work with its airport, airline, and route datasets, or extend an existing PHP application. It is a poor fit for teams seeking a current, isolated service framework because the repository uses PHP 7.4, has incomplete tests, and requires manual assembly of dependencies and containers. Before adoption, verify that the Docker database initializes correctly, that `php/config.php` points to the `db` host, and that the site's specific flight, map, and sharing requirements justify operating the legacy LNMP stack.

Frequently asked questions

Official sources

1. Issues
2. jpatokal/openflights on GitHub
3. License: AGPL-3.0
4. Project website
5. README