Symfony Client Bundle Laravel Package

Product Decisions This Supports

• Decoupling deploy from release. Unleash is an open-source feature-flag/progressive-delivery service; this client wires it into a PHP application so product and engineering can gate features per user, cohort, percentage rollout, or environment without redeploying. That directly supports trunk-based development, canary/gradual rollouts, and fast rollback of a bad release (kill switch) rather than a revert-and-redeploy cycle.
• Roadmap sequencing and risk. Flags let you ship dark, dogfood internally, and ramp by segment — useful for pricing/packaging changes, onboarding rewrites, and migrations where you want a rollback lever. It also enables per-account entitlements/beta access without bespoke conditional code.
• Build vs. buy. The alternative is a homegrown flag table plus admin UI plus audit trail plus SDK caching. This package is the cheap side of that trade: adopt the upstream Unleash server (self-hosted, OSS) and let the vendor community maintain the client, evaluation strategy, and consistency semantics. Buy/adopt unless flag evaluation is a genuine differentiator.
• Platform upgrade planning. This release (v0.12.285) widens the constraint to allow Symfony 8, alongside a bump from v0.12.182. For a PM this is a maintenance-readiness signal, not a feature: it means the client is tracking upstream framework releases, so it will not be the blocker on a Symfony 8 / PHP 8.4+ upgrade. Treat it as reducing "framework upgrade risk" on the roadmap, not as a user-facing capability.

When to Consider This Package

Consider it when:

• You run a Symfony application (or a stack that boots Symfony bundles) and want feature flags without writing an SDK integration yourself.
• You want self-hosted / OSS flag management for data-residency, cost, or procurement reasons, and are willing to operate the Unleash server.
• You need standard progressive-delivery primitives — gradual rollout, user/segment targeting, kill switches, environment separation — more than exotic experimentation statistics.
• You are planning a Symfony 8 / newer PHP upgrade and want the flag client to be an enabler rather than a migration item (this release's only change).

Look elsewhere or pause when:

• You are on Laravel. This is a Symfony bundle; Laravel does not consume bundles the way Symfony does. Laravel teams should evaluate the framework-agnostic Unleash PHP SDK (unleash/client) directly, or the Laravel-specific integration, and only fall back to this package if you genuinely boot Symfony kernels. Verify fit before committing — this is the single biggest misread risk with this package.
• You need no external service at all — a config-file or database flag table may be sufficient at small scale.
• You need experimentation/statistics as the primary use case (A/B analysis, significance testing); that is a different product category.
• Version maturity matters. The 0.x line signals no API stability guarantee; the changelog here is a version-constraint widening with a large numeric jump (v0.12.182 → v0.12.285), so pin versions and read the intervening changelog before upgrading in production.
• You require a vendor SLA/support contract; this is community-maintained OSS.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can separate "deploying code" from "turning a feature on," using an open-source, self-hostable flag service instead of building one. Business impact is lower release risk (ramp a change to 1% → 100%, or switch it off in seconds without a redeploy), faster time-to-market for gated/entitled features, and no per-seat SaaS spend or third-party data sharing. Cost is engineering setup plus running a small service. The latest client release is a compatibility update — it adds Symfony 8 support — which tells us the client is actively maintained and will not block our planned framework upgrade.

For engineering: Adopt the upstream Unleash server and this maintained client rather than a bespoke flag table. The current release is a dependency-widening only — it permits Symfony 8 and bumps the patch line from v0.12.182 to v0.12.285; expect no code changes, but pin the version and scan the intervening 0.x changelog before rolling to production, since the project is pre-1.0 and makes no API-stability promise. Caveat to confirm first: this is a Symfony bundle — if the consuming app is Laravel, validate whether the bundle's service-provider wiring applies or whether we should use the plain PHP SDK instead. Recommended next step: a one-sprint spike wiring the client into one low-risk service behind a flag, with a documented fallback path if the integration assumption fails.