Installer Laravel Package

Product Decisions This Supports

• Greenfield API/service kickoff. The installer is a scaffolding tool: it stands up a ready-to-run API Platform project (PHP-FPM, Caddy, PostgreSQL, Mercure, OpenAPI/Swagger, ReDoc, GraphQL) via composer create-project. It collapses "zero to first documented endpoint" from days to hours, which is a direct lever on time-to-market for any new internal or customer-facing API surface.
• API-first roadmap bets. Because OpenAPI, GraphQL, and JSON-LD/Hydra hypermedia are generated from a single resource model, it lets you promise "documented, spec-first APIs" as a product standard without a separate docs or SDK workstream. That supports decisions to expose APIs publicly, ship a developer portal, or standardize contracts across teams.
• Build vs. buy vs. reuse. It reframes the decision from "build an API framework" to "adopt an opinionated distribution." The realistic comparison set is a hand-rolled Symfony skeleton, Laravel + API Resources/Scribe, FastAPI, NestJS, or LoopBack — not "write it ourselves." The installer is the cheap evaluation path for that comparison.
• Standardization across squads. A single reference distribution reduces snowflake service setups, Docker drift, and onboarding time. Useful if you're deciding whether to mandate a house PHP API template.
• Cheap validation spikes. It is disposable by design — a good fit for roadmap experiments (GraphQL vs. REST, hypermedia vs. plain JSON) that need a working artifact, not a production commitment.
• Retrofit vs. rewrite calls. It clarifies a real fork: greenfield services can start here, but existing Symfony apps should pull api-platform/core directly, and Laravel apps should not adopt this at all. That distinction matters when scoping migrations.

When to Consider This Package

Consider it when:

• You are starting a new PHP service and want an API-first baseline without assembling Symfony, Doctrine, Caddy, Postgres, and docs tooling yourself.
• Your team is Symfony-comfortable (or willing to invest). API Platform's resource/state-provider conventions assume Symfony and Doctrine idioms.
• You need OpenAPI, GraphQL, and/or hypermedia out of the box and value convention over configuration.
• You want a consistent developer environment (Docker-based) shared across teams or contractors.
• You are running a time-boxed spike and want a realistic artifact fast — the installer is designed to be thrown away.

Look elsewhere when:

• Your stack is Laravel-first. This is a Symfony distribution, not a Laravel package; the conventions, DI container, and routing model do not transfer. Use Laravel + API Resources / Scribe / Orion instead.
• You are adding APIs to an existing Symfony app — composer require api-platform/core is the right move; the installer is for new projects only.
• You need a very small-footprint service. The full distribution bundles Docker, Caddy, Postgres, and Mercure, which may be heavier than a minimal container warrants.
• You require highly custom protocols, routing, or non-standard transports where API Platform's resource abstractions fight you rather than help.
• You are not a PHP shop — FastAPI, NestJS, or Spring are more natural.
• You expect to depend on this as a library. It is scaffolding, not a runtime dependency (0 dependents reflects that by design); treat it as a project generator, not something you require.

How to Pitch It (Stakeholders)

For executives: API Platform's installer is a free (MIT), community-backed way to stand up a standards-compliant API in a new PHP service. It gives us documented REST and GraphQL endpoints on day one, which de-risks API delivery, shortens time-to-first-endpoint, and avoids building documentation and scaffolding ourselves. The parent project has ~9k GitHub stars and active releases. The main caveat is scope: it is a Symfony project template, not a Laravel tool and not something we add to an existing codebase — so it supports greenfield bets, not retrofits.

For engineering: Use it as composer create-project for new API Platform services — it provisions PHP-FPM, Caddy, Postgres, Mercure, Swagger/OpenAPI, and GraphQL, and generates hypermedia REST from a single resource model. The trade-offs: it is opinionated (resource classes, state providers/processors), it assumes Symfony + Doctrine fluency, and the installer package itself is scaffolding — for existing apps, depend on api-platform/core instead. Recommended posture: adopt for greenfield and spikes, evaluate the full distribution's footprint against your service-sizing norms, and budget for Symfony ramp-up if the team is Laravel-centric.