Laravel Site Settings Laravel Package

Product Decisions This Supports

• Runtime configuration over redeploys. This package lets admins change product-facing values (pricing thresholds, feature limits, copy, contact details, integration endpoints) from a GUI without a code release or engineering ticket. That directly shortens the change→feedback loop for operational and growth teams.
• Build vs. buy (buy, with a small asterisk). The scope is narrow: cached key/value settings persisted in MySQL plus an admin surface for MoonShine or Filament. Writing this in-house is a few days of work; adopting the package is faster, but the low adoption (14 stars) and single-maintainer risk mean the decision should be framed as "adopt a small commodity component with a fork/exit plan," not "commit to a platform dependency."
• Use cases it enables now: internal tools and back-office apps, MVP settings panels, replacing hardcoded env/config values for non-sensitive operational settings, marketing copy and branding toggles, numeric limits and quotas edited by non-engineers.
• Decisions it does not support — treat these as out of scope, not as gaps to lobby for:
  • Secrets management (API keys, DB credentials) → remain in vault/env.
  • Feature flagging with targeting, percentage rollouts, or experiment assignment → LaunchDarkly / Unleash / Flagsmith.
  • Per-user preferences or per-tenant settings at scale → separate concern; this package is site-wide settings.
  • Audited, approval-gated config changes (SOC 2, change management) → needs an audit trail this package does not advertise.
• Roadmap signal: if "non-engineers can configure the product" is on your roadmap, this package is a credible first slice to validate demand before investing in a proper configuration service. If it's already validated and growing, this package is a stepping stone, not the destination.

When to Consider This Package

Consider adopting when:

• You are already running MoonShine or Filament for admin. The GUI integration is the actual value here; without it, the package is thin.
• Your settings are site-wide, non-secret, and low blast-radius — a bad value causes a visible-but-reversible problem, not an outage or a data breach.
• You need cache-backed reads and care about not hammering MySQL on every request; caching is the package's stated core feature, not an afterthought.
• You have a small team where a few days of in-house build time has better uses, and you are willing to pin the version and carry a fork if the maintainer goes quiet.
• You accept the maturity profile: 14 stars, last release 2024-02-26, MIT. No security disclosure process, no large user base to surface edge cases, no guarantee of timely fixes.

Look elsewhere when:

• You need typed settings classes, migrations, and a broader contributor base → spatie/laravel-settings is the safer general-purpose default, and its popularity means more eyes on correctness.
• You need secrets, audit logs, approval workflows, or per-tenant settings → this is the wrong layer; plan a config service or an audited admin flow.
• You are not on MoonShine or Filament → you are pulling in a dependency for caching sugar you can write in an evening, without the maintenance exposure.
• You have compliance, security review, or long support horizon requirements → single-maintainer, low-adoption packages rarely clear that bar; the cost of the review likely exceeds the cost of building it.
• You need a guaranteed upgrade path across Laravel majors → verify the package's Laravel/PHP version constraints against your target version before committing; with a single 2024 release, future-major support is a real question you should answer with a spike, not optimism.

How to Pitch It (Stakeholders)

For executives: This is a small, free (MIT), focused utility that lets non-engineers change product settings — prices, limits, copy, toggles — from an admin screen instead of filing engineering tickets. The business value is release velocity and fewer interrupt requests, not new capability. The risk is equally small: the package's job is simple enough that we can replace it with in-house code in a few days if the maintainer stops maintaining it. Recommendation: adopt for internal tools and low-risk surfaces, pin the version, and keep an exit plan. Do not use it for secrets, compliance-audited configuration, or anything where a bad value means an outage.

For engineering: Drop-in cached settings stored in MySQL, with admin UI for MoonShine or Filament — which is the real reason to take the dependency. Scope is deliberately narrow: key/value site settings, cache-aware reads. We pin the version, we confirm Laravel/PHP compatibility with a short spike, and we accept that a fork may be needed. The escape hatch is cheap by design: the schema is a settings table, so migrating to spatie/laravel-settings or an in-house implementation is a bounded task. If we're not already on MoonShine or Filament, skip it and build the 100-line version.

Bottom line for the decision meeting: low cost, low risk, low ceiling. Adopt it where it fits today, don't let it become the foundation of a configuration strategy, and revisit the build-vs-buy call the moment requirements include audit, tenancy, or targeting.