Laravel Settings Laravel Package

Product Decisions This Supports

• Runtime configuration without redeploys. Ops and support can change site copy, limits, or toggles from a database row instead of shipping a release, via settings(), the Settings facade, or php artisan settings:set.
• Feature flags and kill switches. Booleans stored per key (billing.enabled) with a flag() helper and @hasFlag Blade directive let PMs gate a beta feature, price change, or billing panel to a subset of surfaces without coordinating a deploy. Caveat: these are global boolean flags, not percentage-based or per-segment rollouts.
• Per-user and per-team preferences. The HasSettings trait gives any Eloquent model a scoped settings bag ($user->settings()->set('ui.theme', 'dark')), supporting personalization, onboarding state, notification preferences, and tenant branding without a new table per concern.
• Admin settings UI backing store. A single, typed, cache-aware key/value store is exactly what a "Settings" or "Feature Toggles" admin screen needs; the package handles type inference (string, int, float, bool, json), defaults, and cache invalidation so the UI work stays in the UI.
• Build vs. buy for a deceptively small feature. A settings table looks like an afternoon of work but reliably grows into cache invalidation bugs, event hooks, and type-coercion edge cases. This package covers defaults, scoped reads, cache clearing, change events, Blade helpers, and Artisan commands — a reasonable "buy" if the risk profile is acceptable.
• Roadmap sequencing. Because flags live in the database, PMs can sequence a rollout (enable billing for internal users → early access → GA) with config changes, and listen to SettingUpdated to trigger analytics or notifications when a toggle flips.
• Explicit boundary between boot config and runtime config. The package's own guidance keeps secrets and boot-required values in config/ and .env; this is a useful forcing function for teams that have historically stuffed everything into config/ and redeployed to change a headline.

When to Consider This Package

Consider it when all of the following are true:

• The application is Laravel and the team wants a small, MIT-licensed, single-purpose dependency rather than a bespoke settings layer.
• You need global settings plus model-scoped settings (user/team preferences), feature flags, or Blade-visible settings in one consistent API.
• Your model-scoped settings owners have integer primary keys — the current implementation casts model IDs to integers, which rules out UUID/ULID-keyed users and tenants without adaptation.
• You can live with literal dotted keys (site.name is one key, not a nested path) and with model settings not inheriting global defaults (inheritance must be written explicitly).
• You do not need secrets, boot-time configuration, or values read before the database is available to live in settings.
• You are comfortable owning the risk of a very small ecosystem footprint (4 stars, 0 dependents, effectively a single-maintainer package). Mitigation: vendor/fork it, wrap it behind an internal interface, and pin the version.

Look elsewhere when:

• You need targeted or percentage-based flag rollout, experimentation, or an audit/approval workflow for flag changes. Laravel Pennant (first-party) or a hosted flag service is a better fit for progressive delivery; this package is closer to a global on/off switch.
• You need a mature, widely adopted settings package with a large community, long track record, and ecosystem integrations (e.g., Spatie's settings package) — the dependency-risk conversation changes materially at 4 stars and 0 dependents.
• You need nested/structured settings trees or config-file-like grouping; the flat key model will fight you.
• You need audit history of who changed what and when. The package emits SettingCreated/Updated/Deleted events but ships no audit log; you would build that yourself by listening.
• You expect high write volume or cross-service consistency. Writes are DB-backed with cache invalidation, and direct SQL/Eloquent writes bypass both cache clearing and events — a footgun if other systems touch the table.
• You need multi-tenant isolation guarantees beyond one settings bag per model; per-tenant scoping is manual and the integer-ID requirement may block your tenancy model.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel package that lets us change application behavior — feature availability, site copy, limits, user preferences — from the database instead of shipping a release each time. That translates into faster experiments, cheaper rollouts, and fewer emergency deploys for operational toggles. It is low-cost to adopt but has a thin community footprint (few stars, no known dependents), so the responsible framing is: run a time-boxed pilot on one low-risk surface, wrap it behind an internal interface so we can swap or fork it, and vendor the code if we keep it. It should not hold secrets or boot-critical configuration.

To engineering: The API is conventional Laravel — helper, facade, injected SettingsManager, HasSettings trait for model scoping, @setting/@hasFlag Blade directives, settings:* Artisan commands, and SettingCreated/Updated/Deleted events that fire after commit. Caching is built in and invalidated on writes through the manager. Known constraints to design around: integer model IDs only, no global-to-model inheritance, literal dotted keys, 'false' string is truthy for flags (pass native booleans), and direct repository/SQL writes bypass cache invalidation and events. Recommended integration: adopt behind a thin internal Settings contract, pin the version, add tests for type round-trips, cache-after-write, event payloads, and owner isolation, and treat the package as vendored code we own rather than an upstream we depend on.