API Platform: the installer repository behind a Symfony based API framework

What this repository actually contains

The most common misunderstanding about this project is that the repository is the framework. It is not. The README says it plainly in one sentence: this repository hosts the `api-platform` installer used to scaffold new projects. The framework itself is a set of Composer packages consumed by the project you generate.

So the tree here is small and installer-shaped. `bin/` holds the entry point, `templates/` holds the files copied into a new project, `scripts/` holds the build helper, `src/` the installer logic, `tests/` the test suite, and `composer.json` declares the dependencies. Alongside them sit `phpstan.neon.dist` and `phpunit.xml.dist` for static analysis and tests.

The distinction matters when you evaluate the project. The README's feature list, which covers hypermedia REST, GraphQL, JSON-LD, Hydra, HAL, JSON:API, YAML, XML and CSV content negotiation, an OpenAPI documentation generator, a React admin interface and client generators for Next.js, Nuxt and React Native, is describing the framework's capabilities. What lives here is the thing that lays those packages out on your disk and asks you questions first.

Installing a static binary instead of a Composer package

The recommended install path skips Composer entirely and downloads a binary built for your platform:

curl -L https://github.com/api-platform/api-platform/releases/latest/download/api-platform-linux-x86_64 -o /usr/local/bin/api-platform
chmod +x /usr/local/bin/api-platform

That is a deliberate choice for a tool whose whole job is to create a PHP project. The installer needs a PHP runtime to run, but you would not want to install PHP first just to obtain something that generates a PHP project. Putting the binary on your `$PATH` first and letting it decide what PHP version your target project needs is the cleaner ordering.

The Composer route exists for people who already have both PHP and Composer:

composer global require api-platform/installer

After that the binary lands in `~/.composer/vendor/bin`. Note that the static binary download is named for a specific platform, `linux-x86_64`, so the releases page is where you find the equivalent for your own architecture and operating system.

An interactive wizard, or flags if you already know the answers

Running the binary with no arguments starts an interactive wizard, which is the path to take if you do not yet know what the choices mean. The usage examples show the flag-driven alternative:

api-platform                # interactive wizard
api-platform my-app --framework=symfony --with-docker --with-pwa
api-platform my-app --framework=laravel

The `--framework` flag is the one decision that shapes everything else. Symfony is the default lineage, since the README describes the server component as built on top of Symfony, and `--framework=laravel` is offered as an alternative. Everything else is additive: `--with-docker` for a containerised development and production setup, `--with-pwa` for a Progressive Web App scaffold.

The PWA and mobile scaffold options are the client generator at work. The README points at client generators for Next.js on React, Nuxt on Vue and React Native, and notes a Vue generator is also available. That is a lot of scaffolding choices for one command, and the wizard exists partly to walk you through them rather than leave you to read flags.

Building a single executable with static-php-cli

The `Makefile` is the most instructive file in the repository, because it documents how a PHP application becomes a dependency-free binary. Three targets matter: `install`, `test` and `build`.

test:
	vendor/bin/phpunit

Tests run through PHPUnit directly, with no wrapper or container. The build target is more interesting and it runs in a specific order. It creates the `dist` directory, installs production dependencies with `--no-dev` and an optimized autoloader, then runs `scripts/build-phar.php` to assemble a PHAR. After that it restores the full dependency install so the working tree is usable again, and only then does the static-php-cli part run.

The `spc` commands that follow are what turn the PHAR into a native executable. `spc download` fetches the extensions listed in `--for-extensions=phar,filter,tokenizer,mbstring,ctype,zlib,curl,openssl`, `spc doctor --auto-fix` repairs the environment, `spc build` compiles a binary with exactly those extensions, and `spc micro:combine` merges the PHAR into the final target and removes the intermediate file. The `clean` target removes both the `dist` directory and a `buildroot`.

Naming that extension list is the useful detail for anyone extending the installer. Anything new the templates need at runtime, such as an image library or a database driver, has to be added to that list in two places, and the build will silently produce a binary that fails at the point of use if you forget.

Symfony foundations, a replaceable ORM, and a React admin

The README is direct about the layering. The server component is built on Symfony, the client components use React with a Vue flavor available, and the default persistence layer is Doctrine ORM. The stated benefit of that choice is reuse: thousands of Symfony bundles and React components are available, and the project can be integrated into an existing Symfony, React or Vue application rather than requiring a rewrite.

The ORM is the part it explicitly does not lock you into. The README notes Doctrine is used by default but is fully optional, and that you can supply your own data provider, naming MongoDB and Elasticsearch as examples. For a framework whose main appeal is an API-first design, that is the sensible escape hatch, and it is worth knowing before you write data fixtures against Doctrine-specific behaviour.

The generated admin interface is the piece most teams underestimate. It is described as a Material Design administration interface built with React, available without writing code. The trade is that you now own a generated frontend you did not write and may need to customise, which is where the React component ecosystem the README leans on stops being a benefit and starts being a constraint.

The project also points at Mercure and Vulcain among its repository topics, both real-time mechanisms that push changes to clients rather than waiting to be polled. That is consistent with the description, which says the project streams changes in real time.

Maintenance cadence and what the release notes do not tell you

The three most recent releases are v10.0.4 on 2026-06-14, v10.0.3 on 2026-06-12 and v10.0.2 on 2026-06-12, which points to a mature line shipping patch releases rather than feature versions. The repository is not archived and the last push was on 2026-09-01.

The release notes for those three tags are empty, which is normal for a stable patch line and unhelpful for judging change. Since this repository is the installer and not the framework, that is the expected shape: framework features land in the packages the generated project depends on, and you will see them in `composer update` output rather than here. The version number of the installer and the version number in your generated `composer.json` will also move independently, which is worth keeping in mind before you assume a scaffolded project can be refreshed by upgrading this binary.

Project attribution is also clear. The README credits Kévin Dunglas as the creator and notes that commercial support is available through Les-Tilleuls.coop. That matters here more than in most projects because the framework's documentation and ecosystem are large, and the paid support relationship is a reasonable signal about who maintains them. The project itself is MIT licensed, with the `LICENSE` file at the repository root.

Editorial conclusion

This repository is worth understanding before you run the installer, because it tells you what a generated project will contain and which defaults you will be inheriting. The binary-first install path is the right choice for trying the framework without a PHP toolchain in place, and the Makefile shows the build is reproducible enough to run yourself with static-php-cli. Two things to verify before scaffolding: whether you want Symfony or Laravel as the base, since both are offered and they imply different bundle ecosystems, and whether the Doctrine ORM default matters to you, because the README is explicit that it can be replaced with MongoDB or Elasticsearch instead. Install the static binary, run it without arguments for the interactive wizard, and compare the generated project against a hand-rolled Symfony API before committing.

Frequently asked questions

Official sources

1. api-platform/api-platform on GitHub
2. License: MIT
3. Project website
4. README
5. Releases