Blogr Laravel Package

Product Decisions This Supports

• Runtime configuration without releases. Stored settings that override file-based config let product/ops change behavior — limits, feature flags, copy, integration endpoints — without a deploy. This directly supports decisions like "do we build an internal admin panel?" (no) and "can support fix this without engineering?" (yes).
• Build vs. buy. Adopting this package replaces a bespoke settings table + admin UI + cache-invalidation layer. That is typically 2–4 weeks of engineering plus ongoing maintenance; the package is the cheaper path for teams already on Laravel.
• Roadmap: self-serve configurability. If a roadmap item is "let customers/marketing/CS adjust X without filing a ticket," this is the substrate. It shifts configuration work out of the sprint backlog and into operations.
• Rollback as a product capability. The reset to file values action is a one-click, non-engineering recovery path — a genuine safety valve for support during incidents, and an argument for keeping file config as the canonical default.
• Deployment-pipeline compatibility is now a non-issue. Prior to v2.6.1, php artisan config:cache froze stored overrides into bootstrap/cache/config.php, meaning deletes and resets silently did nothing until the next cache rebuild. For any team deploying with Forge/Envoyer/Vapor/Docker and standard config caching, this was a latent correctness bug — the kind that surfaces as "I deleted the setting and the app still behaves the old way." That adoption blocker is now cleared, and the release is a patch: no breaking changes, no migration, low-risk upgrade (requires a fresh config:cache).

When to Consider This Package

Consider it when:

• You are on Laravel and need DB-backed overrides of existing config values, with file config as the default/fallback.
• Non-engineers (support, ops, marketing) need to change production behavior without a release.
• Your deploy uses config:cache — now explicitly supported — and you want the reset path to actually work.
• You want the settings list to always reflect the database (post-write consistency) rather than a cache that can resurrect a deleted setting.

Look elsewhere when:

• Secrets management. This is not a vault. API keys, credentials, and anything with rotation/compliance requirements belong in a secrets manager, not a settings table.
• Config-as-code governance. If your org requires every configuration change to pass code review and be reproducible from the repo, DB overrides work against that policy.
• Audit and approvals. The release notes make no claims about an audit trail, change history, or approval workflow. If you need "who changed what, when, approved by whom," plan to build it or choose a product that ships it.
• Very high-traffic, latency-sensitive paths. The list is now read once per request rather than cached across requests — a deliberate trade for correctness. Validate that one extra query per request is acceptable for your traffic profile before rolling it into hot paths.
• Heavy multi-tenancy at scale, where per-tenant settings volumes and isolation requirements are better served by a dedicated tenancy/configuration layer.

How to Pitch It (Stakeholders)

For executives: This gives us a supported, low-risk way to change application behavior in production without shipping code. It removes engineering from the loop for routine configuration changes, shortens the time to fix misconfigurations from hours to minutes, and keeps a one-click path back to the known-good file defaults if anything goes wrong. The latest patch fixes a real production hazard — cached overrides that survived deletion — so the risk profile of adopting it is now materially better than it was a release ago.

For engineering: Standard Laravel package, database-backed overrides on top of existing config, with the file values remaining the source of truth and a reset action that clears the compiled config. v2.6.1 corrects a genuine bug: overrides were being baked into bootstrap/cache/config.php during config:cache, which made deletes and resets ineffective. The fix applies overrides only to real requests and stops caching the settings list across writes, trading one query per request for write-after-read correctness. No breaking changes — upgrade and rebuild the config cache.

For support and operations: You can adjust supported settings directly and undo a bad change immediately with reset to file values. You no longer need to wait for a deploy or a cache rebuild for either action.

Known limits to state up front: not a secrets store; no built-in audit trail or approval flow in this release; one settings query per request by design.