Post Install Laravel Package

Technical Evaluation

Architecture fit: ibexa/post-install is not a Laravel package. It is an Ibexa DXP (formerly eZ Platform) deployment/operations support package: install command behavior, Ibexa Cloud/Platform.sh configuration, vhost templates, Varnish VCL, Solr schema, and related deployment artifacts. Its architecture assumes the full Symfony-based Ibexa DXP runtime and version-aligned Ibexa releases. A Laravel application has no natural integration point: there is no Laravel service provider, no Laravel-specific configuration surface, and no runtime API intended for application code. The realistic leverage for a Laravel team is reference material for infrastructure patterns, not a Composer dependency.

Integration feasibility: Technically installable via Composer, but operationally misleading. The package targets Symfony 7.4 LTS in the 5.0 line and is versioned in lockstep with Ibexa DXP (4.6.x and 5.0.x). Pulling it into a Laravel project would add Symfony console/deployment code and Ibexa-specific configuration without providing Laravel-facing value. Feasible use cases are limited to: extracting vhost/VCL/Solr/Cloud configuration patterns into our own infrastructure-as-code, or supporting an actual Ibexa DXP deployment.

Technical risk:

• License risk is the primary blocker. GitHub reports NOASSERTION; the README defines a dual model: Ibexa Business Use License (requires a valid Ibexa DXP subscription for business use) and GPL-2.0. GPL-2.0 is copyleft and can create obligations if code is linked, modified, or distributed with proprietary software. Any reuse in a commercial Laravel product needs legal review before adoption.
• Maturity/validation risk: 8 stars, 0 dependents, and releases that are frequently “No significant changes.” Low external adoption means limited community testing and weak independent support signals.
• Version coupling risk: The package’s value is tied to Ibexa DXP versions and Symfony 7.4. Drift against the target Ibexa release can break installation/deployment hooks.
• Category mismatch risk: Treating this as a general Laravel/PHP package would create unnecessary dependency and maintenance burden.

Key questions:

1. Are we actually running Ibexa DXP, or is this being evaluated for a Laravel application? If Laravel-only, the answer is likely “reference only, do not install.”
2. Which specific artifact do we need: vhost templates, Varnish VCL, Solr schema, Cloud/Platform.sh configs, or the ibexa:install command behavior?
3. Which license path applies to our organization: Ibexa BUL with a subscription, or GPL-2.0? Has legal approved reuse?
4. What Ibexa DXP and Symfony version must be supported, and does the 4.6 or 5.0 line match?
5. Is there a supported upgrade path and security maintenance commitment from Ibexa for this package in our deployment model?
6. Can we meet our needs by copying infrastructure patterns into our own repository rather than taking a dependency?

Integration Approach

Stack fit: Poor as a runtime dependency for Laravel. Acceptable as a reference repository for infrastructure and deployment artifacts if we are building Ibexa-like hosting patterns. Strong fit only inside an Ibexa DXP project where ibexa/post-install is already part of the platform’s expected deployment tooling.

Migration path: Do not migrate a Laravel application onto this package. Instead:

1. Identify the concrete artifact needed (VCL, vhost, Solr schema, Cloud services config, install command behavior).
2. Extract and adapt that artifact into our own repository with attribution and license review.
3. If we operate Ibexa DXP, align the package version to the DXP release line and install it only within that project.
4. If we are Laravel-only, close the evaluation as “not applicable” unless a specific infrastructure artifact justifies a time-boxed spike.

Compatibility: The 5.0 line requires Symfony 7.4-era components and is aligned with Ibexa DXP 5.x. Laravel uses Symfony components internally but not the full Symfony framework, so console commands and bundle-style configuration will not integrate cleanly. PHP version, extension requirements (for example sodium in some editions), and Cloud/Platform.sh assumptions must be validated against our runtime.

Sequencing:

1. Use-case gate: Confirm whether the target is Ibexa DXP or Laravel. If Laravel-only, stop at reference evaluation.
2. License gate: Legal review of Ibexa BUL vs GPL-2.0 before any code reuse or dependency addition.
3. Artifact spike: Time-boxed proof of concept extracting only the needed config into a sandbox.
4. Version alignment: If Ibexa, pin to the matching 4.6.x or 5.0.x release and verify Symfony/PHP compatibility.
5. Deployment integration: Wire only the required deployment hooks and document ownership.
6. Exit criteria: Decide adopt, adapt, or reject; record the decision and rationale.

Operational Impact

Maintenance: Low-to-moderate if used inside Ibexa, because releases follow Ibexa DXP version lines and often contain no significant changes. High if misused in Laravel, because we would own an orphaned dependency with no natural upgrade path. The repository shows releases but little external consumption; maintenance signal is vendor-driven, not community-driven.

Support: Vendor-backed by Ibexa, but support expectations depend on an Ibexa DXP subscription and the applicable license. There is no evidence of broad community support: 8 stars and 0 dependents. Internal runbooks should identify the exact supported version and escalation path.

Scaling: The package itself is not an application-scaling component. Scaling impact comes from the artifacts it carries: Varnish/VCL behavior, Solr schema, vhost configuration, and Cloud/Platform.sh deployment settings. Those can materially affect cache behavior, search, and deployment reliability. Any adoption should include load and failover testing of those artifacts, not just Composer installation.

Failure modes:

• License contamination: GPL-2.0 obligations or BUL subscription requirements are missed.
• Version drift: Package version no longer matches the Ibexa DXP/Symfony version in use.
• Silent misconfiguration: VCL, vhost, or Solr changes are copied without understanding Ibexa-specific assumptions.
• Deployment breakage: Cloud/Platform.sh or ibexa:install behavior changes in non-interactive environments.
• Dependency noise in Laravel: Unused Symfony/Ibexa code increases audit and upgrade surface.
• False maturity signal: Low stars/dependents and “no significant changes” releases are mistaken for stability.

Ramp-up: For an Ibexa/Symfony operations team, ramp-up is low: the artifacts are familiar deployment concerns. For a Laravel product team, ramp-up is high because the domain knowledge is Ibexa-specific, the licensing is non-trivial, and the package does not solve a Laravel problem. TPM recommendation: treat this as an infrastructure reference for Ibexa-style deployments, not as a Laravel dependency; require a clear artifact-level use case and legal clearance before any adoption.