Post Install Laravel Package

Product Decisions This Supports

• Cloud deployment go/no-go for Ibexa DXP. This package is the vendor's reference deployment baseline: vhost templates, Fastly VCL, .platform/Symfony Cloud service definitions, Solr schema fields, cookie/compression rules, and a non-interactive ibexa:install path for CI. If the roadmap includes "ship Ibexa DXP to production on Ibexa Cloud," this is the configuration you inherit instead of authoring.
• Build vs. buy for edge and platform config. Writing Fastly VCL, cache/cookie rules, Solr schema, and web-server vhosts from scratch is undifferentiated risk. Adopting the vendor baseline converts that into a pinned dependency plus an upgrade task.
• Upgrade and migration planning. The release train tracks the platform line (4.6.x and 5.0.x LTS), and the notes reveal the actual migration surface: Symfony 5 → 6 → 7.4 LTS, Node 18 → 22, ibexa:install non-interactive for Cloud, IbexaSetupCommand deprecated in favor of detecting ibexa/cloud, and deployment moving to the Symfony Cloud configurator / symfony-deploy. Those are roadmap line items, not trivia.
• Hardening defaults as product requirements. display_errors off in Cloud, PHP sodium extension present, api/json excluded from compression, restored Ibexa cookie rule — each is a security/reliability control you get for free, and each is a regression risk if you fork or override.
• Scope discipline. This is not a feature library. It exposes no product API; there is nothing here a roadmap item should be built on. Work that "depends on this package" is infrastructure/deployment work and should be estimated and staffed as such.
• Stack fit check. Despite the framing, this is not a Laravel package — it is Symfony/Ibexa DXP specific. For a Laravel product, the only transferable asset is the pattern (post-deploy hooks, edge config versioned alongside app code), not the code.

When to Consider This Package

Adopt when:

• You operate Ibexa DXP (formerly eZ Platform), especially on Ibexa Cloud, Symfony Cloud, or Platform.sh, and need the sanctioned deploy configuration.
• You need a non-interactive install for CI/CD or an ephemeral-environment pipeline.
• You need reference Fastly VCL, Solr schema fields (including the random-field additions), or vhost templates for an Ibexa deployment.
• You are planning a 4.6 → 5.0 upgrade and need to enumerate deploy-config deltas rather than discover them in staging.

Look elsewhere when:

• The stack is not Ibexa/Symfony DXP. A Laravel team should use Laravel Cloud, Vapor, Envoyer, or Deployer — none of which this replaces.
• You need a general-purpose deployment framework; this is a config/reference package, not tooling with a callable surface.
• The licensing is unresolved. The package is dual-licensed (Ibexa Business Use License requiring a DXP subscription, or GPLv2), and the repository metadata reports NOASSERTION. GPLv2 copyleft may be incompatible with your distribution model; get legal sign-off before it enters your dependency graph. Note the GPL leg is offered with "ABSOLUTELY NO WARRANTY."
• You require community support or third-party documentation. Signals are thin — 8 stars, 0 dependents, a README containing only copyright and license text. Release notes are your documentation, and most releases read "No significant changes," indicating version-parity bookkeeping rather than active feature development.

How to Pitch It (Stakeholders)

For executives: This is the vendor's deployment baseline for Ibexa DXP on Ibexa Cloud, not a product component. Its value is time-to-production and risk reduction: adopting it means we inherit Ibexa's vhost, CDN, search-schema, and post-deploy configuration instead of building and maintaining our own. Cost is low — a pinned dependency plus an upgrade task each platform release. Two caveats to fund: licensing must be cleared by legal (dual BUL/GPLv2, metadata reports NOASSERTION), and support comes from the vendor subscription, not the community — the project has minimal public traction, so we should not plan to self-support a fork.

For engineering: Treat it as configuration-as-code, not a library. Pin the version to the platform line (4.6.x or 5.0.x) and upgrade in lockstep — the package is versioned in parity with the DXP, and most releases contain no code changes. Do not fork it; override narrowly and document each override, because the baseline encodes non-obvious controls (errors suppressed in Cloud, api/json excluded from compression, cookie rules, Solr random fields, sodium extension). Track the deprecation of IbexaSetupCommand in favor of ibexa/cloud detection as a concrete migration item, and budget for the Symfony 6/7.4 LTS and Node 22 jumps reflected in the release history.

Bottom line: Conditionally worthwhile — a mandatory adoption if we are an Ibexa DXP customer on Cloud, a non-starter otherwise. Decouple the licensing decision from the technical one so legal review does not become the critical path.