Laravel Settings Laravel Package

Product Decisions This Supports

• Dynamic Configuration Management: Enables storing and retrieving application settings (e.g., feature flags, API keys, UI toggles) as key-value pairs in the database, eliminating hardcoded configs or environment variables for runtime flexibility.
• Feature Flagging: Simplifies A/B testing or gradual rollouts by allowing settings to be toggled via the admin panel without redeploying code.
• Multi-Tenant Support: If the product supports tenants, this package can store tenant-specific configurations (e.g., branding, regional settings) without complex database schemas.
• Build vs. Buy: Avoids reinventing a settings management system, reducing dev time and technical debt. Low-maintenance alternative to custom solutions or SaaS tools like LaunchDarkly.
• Performance Optimization: Built-in caching reduces database queries, improving response times for frequently accessed settings.
• Admin Panel Integration: Can be paired with a CMS or admin UI to expose settings for non-technical users (e.g., marketing teams adjusting promotional banners).

When to Consider This Package

• Avoid if:
  • You need hierarchical or nested settings (e.g., nested JSON configs). This package is flat key-value only.
  • Your settings require complex validation (e.g., schema enforcement, type safety beyond strings). Consider Laravel’s built-in config system or a dedicated package like spatie/laravel-settings.
  • You need audit logs or versioning for settings changes. This package lacks built-in history tracking.
  • Your team prefers environment variables for all configs (e.g., for security-sensitive values like secrets).
  • You’re using Laravel <5.5 and unwilling to manually register the service provider.
• Look elsewhere if:
  • You need user-specific settings (e.g., per-user preferences). Use Laravel’s built-in Session or a dedicated package like spatie/laravel-activitylog.
  • Your settings require high concurrency (e.g., real-time updates). Consider Redis-backed solutions or event-driven architectures.
  • You need advanced access control (e.g., role-based setting permissions). This package assumes all settings are globally accessible.

How to Pitch It (Stakeholders)

For Executives: "This package lets us centralize and dynamically manage app settings (like feature toggles or UI themes) directly in the database—no more redeploys for small changes. It’s lightweight, caches settings for speed, and integrates seamlessly with Laravel. For example, we could let the marketing team enable/disable promotions without touching code. Low risk (MIT license), minimal dev effort, and future-proof for multi-tenant needs."

For Engineering: *"A drop-in solution for key-value settings with caching. Pros:

• Zero SQL queries for cached settings (performance boost).
• Simple API: Settings::get('key') or Settings::all().
• No schema headaches: Auto-migrates a clean settings table.
• Extensible: Can add validation or events later if needed. Cons:
• Flat structure only (no nested configs).
• No built-in audit logs (but we can layer that on top). Recommendation: Use for non-sensitive, dynamic configs (e.g., feature flags, UI toggles). Pair with Laravel’s config system for static values."*

For Developers: *"Install with composer require solomon-ochepa/laravel-settings, publish the migration, and start using Settings::set('key', 'value') or Settings::get('key'). Caching is automatic. Ideal for:

• Feature flags: if (Settings::get('new_ui_enabled')) { ... }
• Theming: Settings::get('primary_color')
• Regional settings: Settings::get('currency', 'USD') Skip if you need complex data structures or audit trails."*