Parameter Bundle Laravel Package

Product Decisions This Supports

• Dynamic, database-backed application parameters: v1.0.0 ships a Parameter entity, a ParameterProvider, and a ParameterLoader with an accompanying ParameterLoadCommand. This supports the classic "ops needs to change a value without a deploy" use case — thresholds, feature toggles, per-environment settings, integration IDs, messaging/queue names, copy strings.
• Build vs. buy for an internal settings store: the bundle covers the full vertical slice (persistence → provider → loader → CLI warm-up → admin UI). If your roadmap has "admin-editable settings" as a backlog item, this is a credible starting point to fork or vendor rather than greenfield.
• Admin-facing configuration surface: the Sonata-based ParameterAdmin means non-engineers (support, ops, marketing) can edit parameters through an existing back office instead of filing tickets. That directly affects support-load and time-to-change metrics.
• CLI/deploy-pipeline integration: the load command suggests a cache-warming step in CI/CD, which is the right pattern for making DB-stored config safe for production reads. Useful for roadmap items around zero-downtime deploys and config drift elimination.
• Use cases to scope carefully: good for low-cardinality, low-churn operational parameters. Not a substitute for a real feature-flag platform (targeting, gradual rollout, experiment assignment) or a secrets manager. Treat it as "editable config", not "experimentation infrastructure".

When to Consider This Package

Adopt / prototype when:

• Your stack is Symfony, not Laravel. Despite being catalogued as a Laravel/PHP package, this is a Symfony bundle (smartbooster/parameter-bundle) using Symfony bundle Configuration, a Doctrine-style entity, and a Sonata admin class. In a Laravel codebase this is not drop-in — you would be porting concepts, not installing a package.
• You already run Sonata Admin. The admin integration is a large part of the value; without Sonata it is dead weight you must strip or replace.
• You need a small, self-hosted parameter store with no external SaaS dependency, and you accept owning the code.
• You can absorb v1.0.0 maturity risk: this is an initial release (issues #1 and #2), so expect thin documentation, no migration story, and an API that may move before 1.x stabilizes.

Look elsewhere when:

• You are on Laravel — prefer native config/caching plus a maintained settings package, or a dedicated flag service.
• You need targeting, percentage rollouts, audit trails, or approval workflows — evaluate Unleash, Flagsmith, LaunchDarkly, or a config service with those primitives.
• You need secrets management — parameters in a DB table with an admin UI are the wrong tool; use Vault, AWS Secrets Manager, or sealed secrets.
• You want vendor-backed support, SLAs, or a large contributor base. A single-maintainer bundle is a bus-factor decision, not just a technical one.
• Your need is satisfied by static config + environment variables. Adding a DB table, cache-warming step, and admin surface is real operational cost for a problem you may not have.

How to Pitch It (Stakeholders)

For executives: This is a small, early-stage open-source Symfony bundle that lets operations staff change application settings from an admin screen instead of requesting code changes. The business case is reduced lead time for config changes and fewer engineering interruptions — but v1.0.0 is a first release from a single maintainer, so the recommendation is a time-boxed spike, not a platform commitment. It is not a feature-flag or experimentation platform, and it is not a secrets store; positioning it as either would create security and roadmap risk.

For engineering: Initial release delivers the complete loop — parameter entity, provider, loader, a load command suitable for deploy-time cache warming, and a Sonata admin screen. Two caveats to weigh before adoption: (1) it is Symfony/Sonata-specific, so a Laravel team would be reimplementing the pattern rather than consuming the package; (2) at v1.0.0 there is no deprecation policy, migration guidance, or track record. Suggested next step: a one-sprint spike in a non-critical service to validate the load-command/caching behaviour under real deploy conditions, confirm the entity schema and cache invalidation semantics, and decide between adopting, forking, or building a thin in-house equivalent. Budget for the fork scenario — with a package this small, that is the likely long-term outcome and should be priced in up front.