Laravel Settings Laravel Package

Product Decisions This Supports

Feature: self-serve runtime configuration. The primary product unlock is moving configuration out of code and into an admin surface — pricing tiers, feature toggles, notification copy, rate limits, per-tenant branding — without a deploy or a developer in the loop. That’s a "make operations faster" win, not a "make the product do something new" win, and should be justified on operational velocity rather than user-facing features.

Build vs buy: buy the storage layer, own the semantics. A key/value table with get/set helpers and caching is ~150 lines of code to build. The honest reason to buy is to skip the migration, the value-type serialization edge cases, and the cache-invalidation footguns. The honest reason to build is that this package is at 7 stars, last shipped in December 2022, and has no published changelog for its most recent version — meaning you are the maintainer in practice. For most teams the right call is: use this package as a reference implementation, evaluate it against spatie/laravel-settings (actively maintained, far larger install base) before committing, and only adopt it directly if the API surface genuinely saves you a sprint.

Roadmap items this unblocks or accelerates:

• Admin-editable business rules (fees, thresholds, banners) without CI/CD dependency.
• Lite feature-flagging for internal/exposed-beta gating, ahead of a real flag service.
• Model-scoped preferences: per-tenant, per-user, per-project settings on any Eloquent model — this is the differentiating capability versus a flat config override and is the one most likely to create durable product leverage.
• White-label / multi-tenant configuration, if the query pattern for model-scoped reads is efficient — that is an unverified assumption and must be load-tested before it goes on a roadmap commitment.
• CMS-adjacent settings panels that would otherwise justify an expensive headless-CMS purchase.

Portfolio / roadmap-level risk to flag now: a dependency with 7 stars and an 18+ month-old release is a single-maintainer, near-abandoned bet. Before it appears on a roadmap as a dependency, the roadmap needs a contingency line item: either a wrapper/adapter owned by us (see pitch below) or a planned migration to spatie/laravel-settings. Do not let it become load-bearing on a revenue-critical path without that.

Decision framing for scope: treat this as a lever for operational velocity, not as infrastructure. If the setting you want to expose can break checkout, payments, or auth when misconfigured, this package is the wrong abstraction — you want typed, validated, versioned config with an audit trail, which this does not claim to provide.

When to Consider This Package

Adopt when all of the following hold:

• You are on a Laravel version still supported by a 2022-era package — verify composer.json constraints against your framework version first; this is the single most likely reason to walk away.
• Your need is genuinely simple key/value: strings, numbers, booleans, arrays, with optional configurable defaults. No versioning, no approval workflow, no per-field validation, no audit log requirements.
• The write path is trusted operators (internal admin, ops, support), not end users.
• You are willing to wrap it in a single internal adapter (App\Support\Settings) and bind to a contract so a swap to Spatie or in-house code is a one-file change. This is a non-negotiable precondition — it converts an abandoned-package risk into a routine refactor.
• You have a staging environment where you can verify the resolved cache driver and the database write path before production, and a CI suite that can pin the version and prove it still boots on your Laravel version.
• Model-scoped settings are the actual requirement. If you only need global app settings, Laravel’s own config + a small table is cheaper than any dependency.

Look elsewhere when any of the following is true:

• Compliance, audit, or change-history requirements. Settings that affect money, access, or regulated behaviour need who-changed-what-when. Not offered here.
• High query volume on model-scoped settings. N settings reads per request across N models is an N+1 trap. If you cannot confirm the caching story covers your access pattern, you will be re-architecting under load.
• Octane or long-lived workers. The engineering review flags that singletons holding request state will leak across requests, and the package predates being Octane-tested. That is a hidden cost, not a blocker — but budget for it.
• The team cannot tolerate a stale dependency. If your policy is "no dependency without a recent release and an active maintainer," this fails on day one. Use spatie/laravel-settings (much larger install base, active) or build the ~150 lines.
• You need typed settings objects, casting to DTOs, or per-tenant isolation guarantees. Spatie’s typed settings classes are the better fit for that model.
• A single-maintainer, 7-star package on a critical path is the decision you are actually making. If your org has a supply-chain or dependency-review policy, this package will not clear it, and that is a legitimate answer, not an obstacle.

Sizing the call: treat adoption as an experiment, not a commitment. One sprint, one narrow read-only integration, feature-flagged, with a documented exit path. If the exit path (the adapter) is cheap — and it is — the risk is manageable and the buy-vs-build decision becomes reversible, which is the actual product decision.

How to Pitch It (Stakeholders)

For the executive summary (one paragraph):

We can move business configuration — pricing rules, feature toggles, admin-editable copy — out of code and into an admin surface without adding engineering to every change request. The candidate library is a lightweight, MIT-licensed Laravel package that stores settings in the database with caching and per-model scoping. It is small (7 GitHub stars), last released in December 2022, and has no published changelog, so we will adopt it behind our own thin abstraction layer and treat it as a reversible, low-cost experiment rather than a platform commitment. Expected benefit is faster operational iteration; expected cost is one sprint of integration plus a maintained adapter. If it does not clear our dependency review or fails the staging check, we fall back to a well-maintained alternative or ~150 lines of in-house code, and the admin surface still ships.

For engineering (the pitch they need to hear):

We take the package for the storage and caching layer only, not as an architectural dependency. Concretely:

1. Contract-first. Bind an App\Contracts\SettingsStore interface in a service provider and implement it with the package. Nothing else in the codebase references Pharaonic\LaravelSettings\* directly. That one file is our migration path to Spatie or in-house, and it is the reason this is a safe bet.
2. Pin and verify compatibility on day one. The 2022 release may not support current Laravel. The first task is composer require in a throwaway branch, php artisan about, boot the app, run the suite. If it does not install cleanly, we stop there — that is the entire cost of the spike.
3. Confirm config and driver resolution with a boot test. Package config can silently fall back to a default driver. We assert the resolved cache driver and storage in a test so "nothing happens" never becomes a production incident.
4. Model-scoped reads get a caching story before they ship. Any per-tenant/per-model setting access goes through our adapter, which owns the cache and the invalidation — not the package.
5. Octane: register as scoped, not singleton, in our own provider, and add it to the warm/flush lists. Assumed, then verified under load.
6. Write path behind a feature flag. Read-only integration first, then admin writes, then flag on. Shadow-mode any setting that feeds a critical path for one release cycle.
7. No published changelog means no silent upgrades. Version pinned in composer.json, upgrades only via an explicit branch and a full-suite run. vendor:publish --force diffs reviewed by hand, since a no-op publish silently drops new config keys.

Net: a small, contained bet with a defined exit, delivering an admin-configurable settings surface in one sprint.