The Game Panel specification

ADR-0009: The panel runs as a FrankenPHP worker in a single binary

Context

The panel is one system, shipped as a single binary, per ADR-0001.

The panel is installed and run by the people who host it. A PHP application is usually installed as a project: the right PHP version, its extensions, its Composer dependencies and a web server all have to be in place before it runs, as they do for Pterodactyl. That is a high barrier to entry.

A PHP application served the usual way also boots again for every request, and discards everything it built once the response is sent.

Decision

The panel is distributed as a single binary built with FrankenPHP, with the whole application compiled into it, so that it is installed as a product rather than set up as a project. It runs in FrankenPHP’s worker mode, with Caddy underneath: the application boots once, and a long-running process serves every request. The engine commits to this one runtime, and nothing in it abstracts over server APIs it will never run under.

Alternatives

Installing the panel as a PHP project, as Pterodactyl is installed. Whoever installs it has to provide the right PHP version, the Composer dependencies and the rest, which is a much higher barrier to entry than a single binary.

Other PHP runtimes. FrankenPHP is chosen over them because it can compile the entire application into a single binary, which is what lets the panel be distributed as an installable product. Which runtimes were weighed against it is not recorded.

Booting the application for every request. A long-running worker process is more efficient.

Abstracting over server APIs, so that the engine could run under more than one. The panel only ever runs inside this binary, so the engine commits to one runtime instead.

Consequences

Easier:

Harder:

Constrained:

Sources