Composite Config Laravel Package

Product Decisions This Supports

• "Should this behavior live in code, config, or data?" — and the package argues for data. Every per-customer nuance (plan limits, branding strings, locale defaults, integration endpoints, toggles) that today forces an .env edit and a deploy becomes a row instead. That is the single decision this package makes cheap, and it recurs on nearly every B2B roadmap.
• Multi-tenant and white-label viability. Layering a database source over illuminate/config's filesystem source with explicit precedence is the mechanics of per-tenant configuration. If a named-account or brand-specific ask is on the table, this is the "can we serve it from one codebase?" answer — quantified as the number of config/brand-*.php forks you currently maintain and diff-review on every framework upgrade.
• Enterprise-tier pricing and packaging. Once config is a resolvable, layered source, "custom quota for this account" stops being a bespoke engineering commitment and becomes a support operation. The package is plumbing, not the admin UI, but it is the prerequisite that moves "customer settings page" from a project estimate to a sprint.
• Build vs. buy — a decision with an unusually clear answer here. The described behavior is a decorator around Illuminate\Contracts\Config\Repository: read the DB layer, fall through to files, preserve dot-notation and defaults. A few hundred lines for a competent Laravel engineer, fully testable, owned in-house. Against that you weigh a package with 0 stars, 0 dependents, one release in December 2020, and a NOASSERTION license. The capability is worth funding; the dependency is not.
• Deployment and cache topology, which is a PM-level cost. php artisan config:cache yields one serialized config per deploy; per-tenant config implies one cache entry per tenant, warmed on write. That changes your release process and invalidates "settings take effect immediately" as a promise unless you plan for it. True of any solution in this space — but someone has to own the tradeoff, and that someone is product.
• Scope boundary against feature flags. If the actual ask is "show feature X to 10% of accounts," this is the wrong instrument — Pennant or a hosted flag service gives targeting, exposure tracking, and instant kill switches. This package answers "what are the values," not "who gets the feature." Confusing the two is an expensive and common mis-scoping.

When to Consider This Package

Consider adopting only when every one of these holds: you are on a Laravel line the package actually targets (its history stops at PHP 8.0 / December 2020); the requirement is static layered values rather than runtime targeting; you are prepared to vendor the source into your repo and own it; and legal has cleared the license text directly — the metadata says NOASSERTION, so do not assume a grant you haven't read.

More realistically, treat it as a reference implementation rather than a dependency. Zero stars, zero dependents, no release since 2020 means no community, no security-response path, no one to escalate to — and a config layer sits on the boot path of every request, which is an unusually high blast radius for an unsupported component. The honest play is to read how it composes the repository and then write the ~50–300 line version you control.

Look elsewhere when:

• The requirement is flagging, cohort targeting, or A/B rollout. Use Laravel Pennant or a hosted provider.
• You need an SLA, a support contract, or a CVE response. A single-maintainer, single-release package supplies none of these.
• The values are secrets. Database-backed config is not a secrets store; encryption at rest, rotation, and audit belong to a vault.
• You are on Laravel 10/11/12 or PHP 8.1+. No evidence of support, and the illuminate/* constraints are unlikely to resolve without patching.
• The surface is small or single-tenant. Below roughly three or four overriding values, a config file plus an environment variable is cheaper than either option — and cheaper to explain to the next engineer.

If you override the above, gate adoption behind a time-boxed spike with a hard kill criterion: pin the exact version, confirm the declared php and illuminate/* constraints, verify a single non-secret key reads correctly through config() with config:cache both on and off, and confirm boot still succeeds against an empty database. Fail any of those and stop — the fallback is your own decorator.

How to Pitch It (Stakeholders)

Executives: "We keep paying engineering to change per-customer behavior — limits, branding, integrations — and each workaround becomes a config fork that drifts on every framework upgrade. The pattern here moves those values from code into data we control, which is what makes a self-serve customer-settings capability possible at all. The specific package is abandoned, unclear on licensing, and unmaintained since 2020, so the ask is not to buy it. The ask is a small, bounded build of the same pattern — days, not weeks — because we are going to own this code either way."

Engineering: "The behavior is a decorator on Illuminate\Contracts\Config\Repository — DB layer first, files as defaults, dot-notation and defaults preserved so no call site changes. We keep the schema and the write path; we bind it once and can swap it out without hunting call sites. Two non-negotiables: guard the boot-time read (schema check plus fallback) so a fresh clone or a CI job without a database doesn't hard-fail before the error page renders, and decide explicitly whether config:cache bakes in overrides or bypasses them — test both states, because that's where this quietly breaks. Also: never persist through config([...]), cache the override set per tenant rather than per key, keep credentials out of the table entirely, and accept that long-running workers need a restart to see a change."

The one-line version for a roadmap review: this is a small, well-understood piece of infrastructure that unlocks per-tenant configuration and a self-serve settings surface — fund the pattern, not the package.