Laravel Eloquent Settings Laravel Package

Product Decisions This Supports

• Feature scoping for per-entity configuration: An Eloquent-backed settings package is the right fit when settings belong to a domain object (user preferences, tenant/team config, per-project toggles) rather than to the application as a whole. This release (v0.2.0) adds Laravel 11 support, so it becomes viable for new builds and upgrades rather than only legacy 10-and-below work.
• Build vs. buy: Adopting this package replaces the "settings table + JSON cast + accessor helpers" work your team would otherwise write in a day or two — small but repeated across projects. Buy/borrow is the default; build only if you need audited change history, typed schemas, or cached bulk access.
• Roadmap sequencing: Laravel 11 compatibility is a gating criterion, not a feature. Treat this as clearing a blocker for teams standardizing on L11; it does not add product capability.
• Upgrade planning: If you run Laravel 10 today and are planning an 11 migration, this package is no longer an upgrade risk in your dependency audit — remove it from the "replace or fork" list.
• Not supported by this release: No new features, no API surface changes, no performance or caching improvements. Do not let this release drive any roadmap item beyond framework-version readiness.

When to Consider This Package

Consider it when:

• You need settings scoped to a model instance (per user, per tenant, per record) rather than global config keys.
• Your team is on Laravel 10 or 11 and wants a small, dependency-light abstraction over a settings table.
• You want a short integration surface — a trait plus accessors — that junior engineers can read in an afternoon.
• The settings are read-often, write-rarely, and a straightforward DB read per access is acceptable for your query budget.

Look elsewhere when:

• You need global application settings — Laravel's config plus a cached settings package (e.g. spatie/laravel-settings) is a better conceptual fit for typed, class-backed settings.
• You require typed values, validation, encryption, or an audit trail of who changed what and when. Nothing in this release indicates those exist.
• Hot-path performance matters: no evidence of caching in the changelog. If settings are read on every request in a loop, plan to wrap it in your own cache layer or choose a package that ships caching.
• Maturity is a criterion: v0.2.0 is pre-1.0. Two of five changes in this release are Dependabot bumps and one is StyleCI formatting — the release is largely maintenance. Expect a small maintainer surface area and evaluate bus-factor risk before putting it in a critical path.
• You need enterprise support, SLAs, or a security review process. A single-maintainer pre-1.0 package won't satisfy procurement in regulated environments.

How to Pitch It (Stakeholders)

For executives (one line): A small open-source helper that lets our Laravel apps store per-customer and per-user settings in the database without custom code; the new v0.2.0 release confirms it works with Laravel 11, so it clears a framework-upgrade blocker but adds no new capability.

For engineering leads:

• v0.2.0 is a compatibility and hygiene release: Laravel 11 support, CI action bumps, a code-style pass, and .gitattributes cleanup. No new features, no breaking changes, no deprecations.
• It unblocks Laravel 11 adoption for anyone currently pinning to the older version — this is the only decision-relevant change in the release.
• The package remains pre-1.0 and single-maintainer; treat it as a convenience abstraction, not critical infrastructure. Keep a fallback path (a hand-rolled settings table) in mind if maintenance stalls.
• Recommendation: approve for Laravel 10/11 work where settings are model-scoped and read volume is moderate; do not adopt for global config, typed/encrypted settings, or high-frequency read paths without an added caching layer.