Config Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for a runtime settings layer: The package encodes the pattern of persisting configuration in a database and resolving it at runtime with typed values, defaults, and overrides. It is useful as a reference design when scoping an admin-editable settings feature (feature flags, per-tenant overrides, pricing limits, integration credentials) — not as something to adopt.
• Where configuration should live: It forces the decision between deploy-time config (env files, versioned YAML/PHP) and operator-editable config (DB-backed, changeable without a release). Most products need both layers; this package represents the second tier and shows how to shape it.
• Who owns changes: DB-backed config shifts change control from engineering releases to ops/support/admin users. That is a product and support-cost decision — who can flip a flag, what gets audited, what can break silently — far more than a technical one.
• Roadmap sequencing: If a settings/admin console is on the roadmap, decide early whether config is a first-class domain object (typed, validated, cached, versioned, with fallbacks) or an ad-hoc key/value table. The latter is what teams regret by month six.
• Use cases it validates: Multi-tenant overrides, per-environment tuning, third-party API credentials, and "turn this feature off in production without a deploy" — recurring asks that justify a dedicated config capability.

When to Consider This Package

The honest answer: rarely, and not as a dependency.

• It is not a Laravel package. modera/config-bundle is a Symfony bundle. On a Laravel stack it does not apply directly; the equivalent decisions are served by spatie/laravel-settings, Laravel's own config repository plus a cached settings table, or a small in-house implementation.
• Only as a design reference, if you are on Symfony and want to see how DB-backed, handler-per-property configuration was modelled circa 2015. Read the source; do not install it.
• Disqualifying signals for adoption: 1 GitHub star, 0 dependents, last release July 2016, repository marked [READ-ONLY] as a subtree split from a monorepo. That combination means no maintainer, no security patching, no compatibility with modern PHP/Symfony, and no community to absorb bugs. Any production dependency here is a supply-chain and maintenance liability your team will own.
• Look elsewhere when: you need supported maintenance, current framework compatibility, typed and validated config schemas, cache invalidation, audit trails, secret encryption, or multi-tenant scoping. Build a thin in-house layer (typically a few days' work) or use a maintained package — the domain is small enough that owning it is cheaper than owning a dead dependency.

How to Pitch It (Stakeholders)

Executives: We evaluated this package for the "change settings without a deploy" capability and recommend not adopting it. It is an unmaintained Symfony bundle — last shipped in 2016, one star, no downstream users, read-only — so the true cost of adopting it is the cost of maintaining it forever, with no security support. The underlying idea is sound and worth funding: a database-backed configuration layer that lets ops adjust limits, flags, and credentials without engineering releases. We recommend a small in-house build scoped to a few days, delivering typed settings, validation, caching, and an audit trail — none of which this package provides. Net recommendation: reference it, don't depend on it; budget the small build instead.

Engineering: Treat it as prior art, not a dependency. It confirms the pattern — persist properties, resolve at runtime, allow overrides — but predates modern PHP and Symfony, has no test or maintenance story, and adopting it would be a one-way fork. We will implement the pattern directly: a settings table with typed columns or a validated schema, a cached resolver with explicit defaults and a defined fallback order (DB → container parameter → literal), an admin surface with change logging, encryption for secrets, and a clear rule for what stays in versioned config versus what becomes runtime-editable. Effort is low relative to the support burden we avoid, and the result is a first-class capability rather than a dead dependency.