Laravel Polymorphic Settings Laravel Package

Product Decisions This Supports

• Deferring a settings service from the roadmap. Per-model key-value settings are a commodity concern most Laravel products eventually need (tenant config, user preferences, feature toggles scoped to an account, white-label overrides). Adopting a package here removes a "we should build a settings table" ticket from the backlog and lets the team spend capacity on differentiating features instead.
• Build vs. buy call: buy/leverage. The capability is well-bounded (one trait, a settings table, get/put/forget), so the buy-side cost is low and the opportunity cost of hand-rolling (schema design, cache invalidation, encryption at rest) is real. A PM can justify "leverage open source for undifferentiated plumbing" with a clear conscience.
• Enabling per-entity configurability without schema churn. Polymorphic attachment means any model (Tenant, Team, User, Project) can carry settings without new columns or migrations per feature. That unlocks product experiments — e.g. per-tenant behavior flags, per-user notification preferences, per-project limits — without a database migration for every knob.
• Opt-in encryption as a compliance lever. Sensitive per-tenant values (third-party API keys, webhook secrets) can be stored encrypted with a per-field opt-in, which supports security review conversations and enterprise/regulated-customer requirements without standing up a separate secrets store.
• Transparent caching as a performance default. Settings reads happening on every request is the normal case; caching being transparent means product doesn't need to negotiate a caching story with engineering for each new settings-backed feature.
• A concrete de-risking signal to watch. v0.1.3's two cache-hygiene fixes (dotted-key cache poisoning, forget() no-op after external deletion) came from a real downstream integration. That is evidence the package is being hardened against production use cases — relevant to a roadmap decision about whether to lean on it or wrap it.

When to Consider This Package

Consider it when:

• The product is a Laravel application and the need is genuinely per-record settings — values that vary by Tenant, Team, User, Project, etc. — rather than app-wide configuration.
• The values are small, sparse key-value pairs (feature flags, preferences, limits, integration credentials), not structured documents that need querying, indexing, or aggregation.
• Encryption-at-rest for a subset of values is a requirement or a near-term compliance ask.
• Read volume is high and write volume is modest — the transparent caching is a genuine win in that profile.
• The team wants a small, trait-based surface they can wrap behind an internal interface, so the vendor choice is reversible.

Look elsewhere when:

• The need is global application configuration (use Laravel config/env; a per-model settings table is the wrong tool).
• Settings need to be queried, sorted, filtered, or joined against — a key-value store fights the relational model; model a real table instead.
• Write throughput is high or settings change constantly (cache invalidation churn, and dotted-key literal reads now bypass cache by design — one DB query each, per v0.1.3's stated trade-off).
• The product needs a mature ecosystem commitment: 0 stars, 0 dependents, and a single-package lineage mean bus-factor and long-term maintenance risk are the dominant concerns, not feature gaps.
• There is an existing first-party settings/preferences service or a broader SaaS platform that already owns this concern.

Adoption criteria I'd apply: wrap it behind an internal SettingsRepository-style interface on day one; confirm the test suite (129 tests / 217 assertions at v0.1.3) and the upgrade path are acceptable; pin versions; and confirm the team is comfortable forking under MIT if maintenance stalls.

How to Pitch It (Stakeholders)

For executives: We have a recurring, low-differentiation need — storing small configuration values per customer, team, or user. Building and maintaining that ourselves is a few weeks of engineering plus ongoing ownership of cache invalidation and encryption. This MIT-licensed package covers exactly that concern with a small integration surface, so we can ship settings-backed features (per-tenant flags, per-user preferences, encrypted integration credentials) sooner and redirect engineering to the parts of the product customers actually pay for. The main risk is maturity — it's an early-stage package — which we mitigate by wrapping it behind our own interface so we can swap or fork it without touching product code.

For engineering: It's a Laravel trait that attaches key-value settings to any Eloquent model, with opt-in encryption per value and transparent caching. The API is small — get/put/forget — and the recent v0.1.3 release fixed two real cache-hygiene bugs found in a downstream integration (stale dotted-key caches after migration, and forget() not invalidating cache when the row was already gone). Known trade-off: literal dotted-key reads now skip the cache and hit the DB once per read, which is fine for our access pattern. We adopt it behind an internal settings interface, pin the version, and keep the escape hatch (disable the cache via env, or fork under MIT) if anything looks shaky. Test coverage at the current release is solid for a package this young.