Symfony Rollout Rox Laravel Package

Product Decisions This Supports

This package sits in the feature delivery / release control layer — it wires a PHP application into ROX (a hosted feature-flag service) via the Rollout flag-evaluation model, exposed as a Symfony bundle. As a PM, the decisions it informs are indirect but real:

• Feature flagging as a build-vs-buy decision. It is a worked example of the "buy the control plane, build the thin adapter" pattern. You are not buying flag evaluation logic here — you are buying a small amount of DI wiring, config loading, and service decoration that connects your framework to a vendor. That is the cheap part of any flagging investment, and seeing it isolated tells you where the actual cost and lock-in live (vendor SDK, targeting model, audit trail, flag lifecycle hygiene).
• Release strategy: progressive rollout vs. big-bang. Any package in this category exists to support canary/percentage rollouts, kill switches, and cohort targeting. If your roadmap includes dark launches, beta cohorts, or entitlement gating, this is the capability class you are scoping — even if this specific package isn't the vehicle.
• Framework alignment on the roadmap. Note this is a Symfony bundle, not a Laravel package — despite surface-level PHP compatibility, its value is in Symfony's service container and bundle config conventions. For a Laravel shop, this is a reference implementation at best. That distinction should drive whether "feature flag integration" lands as a sprint-sized ticket or a spike.
• Ecosystem bet on a specific vendor. Choosing ROX means choosing its targeting DSL, its dashboard, and its data plane. This package is the concrete artifact that would encode that bet into your codebase.

What changed in v0.1.0: the release adds automatic and lazy loading of ROX containers. This is a bootstrap-lifecycle improvement, not a capability change: it means flag containers are resolved through the container on demand rather than eagerly, which lowers startup cost and avoids instantiating the flag client on requests that never evaluate a flag. It is the kind of polish you'd expect from a first release of an adapter — useful, but it does not move the vendor-selection or build-vs-buy calculus, and it does not add auditing, caching, fallback, or resilience behaviour.

Bottom line for the roadmap: treat this as research input for a feature-flag evaluation, not as a dependency to schedule. The capability is worth a decision; this package is not the decision.

When to Consider This Package

Adoption criteria — all of which should be true simultaneously:

• You are on Symfony (not Laravel, not vanilla PHP with a hand-rolled container).
• You have already selected ROX as your feature-flag vendor — i.e. the buy decision is made on the vendor's merits (targeting, pricing, compliance, SLA), and this package is only the glue.
• You can vendor or fork it. At v0.1.0 — a pre-1.0 initial release with effectively no community or downstream users — there is no maintainer bench and no signal yet that security or compatibility fixes will arrive on any cadence. Anything you take from here should be code you own.
• You have verified upstream viability: the hosted ROX service and its SDK/API contract must still exist and be supported. A thin adapter is only as durable as the SaaS behind it — this is the first diligence question, before any code review.

Look elsewhere — likely nowhere in this repo — when:

• You are on Laravel. There are maintained first-party and community SDKs for the major flag vendors (LaunchDarkly, Flagsmith, Unleash, GrowthBook) that fit Laravel's service provider model directly. Do not port a Symfony bundle for this.
• You have not yet chosen a vendor. Do the vendor bake-off first; the integration layer is a one-to-two-day cost once the vendor is picked, and should never be the reason to pick a vendor.
• You want a self-hosted or open-source flag system (Unleash, Flagsmith OSS, GrowthBook). This package assumes a hosted control plane.
• You need active maintenance guarantees — audit logging, SOC2 evidence, CVE response, a release cadence and versioning policy. A 0.x initial release with no dependents is a hard fail on supply-chain review until it has a track record.
• Your flagging need is trivial (a handful of boolean toggles, one environment). A config file and a config('features.x') helper beats adding a vendor and an integration layer.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed connector between a Symfony application and a hosted feature-flag service, now at its first tagged release (v0.1.0), which adds lazy container loading so flag clients are only initialised when a request actually needs them. We are not recommending adoption — it is pre-1.0, has no stars, no downstream users, and no maintenance track record, which means no security response and no compatibility guarantee. What it does give us is a cheap, concrete artifact for a decision we do need to make: whether to buy a feature-flag platform, and what the integration cost actually looks like when we do. Recommendation: fund a short evaluation of the flag-vendor landscape against our release process, and treat this repo as a reference sample, not a dependency.

For engineering: It's a Symfony bundle wrapping ROX via the Rollout evaluation model — bundle config, container wiring, and a decorated flag service. v0.1.0 adds automatic and lazy resolution of ROX containers from the Symfony container, which is a real startup-cost win but is roughly a day's work to reproduce. Three concerns before anyone writes code: (1) confirm the ROX service and API contract are still live and supported — a lazy-loading adapter against a dead control plane is worthless; (2) the package is Symfony-specific, so a Laravel target means re-implementing the adapter against the vendor's raw SDK, not porting this; (3) note this is a 0.1.0 initial release — expect the public surface (config keys, service IDs, container semantics) to be unstable, and plan to fork and own anything we reuse rather than tracking upstream. If we proceed with a vendor, we write and own the adapter ourselves and pin the SDK deliberately.

The one-line ask: approve a timeboxed vendor evaluation for feature flagging; do not add this package to any service.