Laravel Settings Laravel Package

Product Decisions This Supports

• Centralized Configuration Management: Replace scattered .env variables or hardcoded values with a structured, type-safe settings system. Enables dynamic configuration without redeployments.
• Feature Flagging & A/B Testing: Store boolean flags (e.g., feature_new_ui) in Settings classes for runtime toggling via admin panels.
• Multi-Tenant or Environment-Specific Settings: Use Redis repositories to isolate settings per tenant/environment (e.g., TenantSettings::class with repository() override).
• Admin Panel for Non-Technical Users: Build a CMS-like interface to update settings (e.g., site_name, maintenance_mode) without code changes.
• Data Migration Strategy: Safely evolve settings schemas via migrations (e.g., rename old_api_key → api_key_v2).
• Build vs. Buy: Avoid reinventing a settings repository layer; leverage this package’s battle-tested abstraction for database/Redis storage.
• Performance Optimization: Enable caching for frequently accessed settings (e.g., cache.enabled = true) to reduce database/Redis calls.

When to Consider This Package

• Avoid if:
  • Your settings are static (use .env or Laravel’s config files).
  • You need fine-grained access control (e.g., per-user settings; consider Laravel’s built-in config + cache).
  • Your team prefers YAML/JSON files over PHP classes (use spatie/laravel-config-array).
  • You require real-time collaboration on settings (e.g., Google Sheets integration; use a custom solution).
• Look elsewhere if:
  • You need versioning for settings (e.g., rollback to previous values; extend with a custom repository).
  • Your settings are hierarchical (e.g., nested groups like app.themes.colors.primary; consider a key-value store like Redis with hashes).
  • You’re using Laravel Nova/Panel: Nova’s built-in settings management may suffice for simple cases.

How to Pitch It (Stakeholders)

For Executives

"This package lets us manage app-wide configurations (e.g., feature toggles, branding, API keys) in a structured, type-safe way—like a database for settings. Instead of hardcoding values or using .env files, we can:

• Update settings via an admin dashboard (no redeploys).
• Enable/disable features dynamically (e.g., A/B tests).
• Support multi-tenant environments with isolated configs. It’s lightweight, open-source, and reduces technical debt from scattered configs. Similar to how we’d use a CMS for content, but for app settings."

For Engineers

"Problem: Managing app settings across .env, config files, and migrations is messy and error-prone. Solution: spatie/laravel-settings gives us:

• Type Safety: Settings are PHP classes (e.g., public bool $maintenance_mode), catching errors at compile time.
• Flexible Storage: Use database (default) or Redis, with custom repositories for advanced use cases.
• Migrations: Safely evolve settings schemas (e.g., rename old_key → new_key) alongside DB migrations.
• Dependency Injection: Inject settings into controllers/services like any Laravel class.
• Performance: Optional caching for frequently accessed settings. Example use case: Replace config('app.feature_flags') with FeatureFlags::class for better tooling and runtime updates."

For Developers

*"Why this over .env?

• No restarts: Update site_name in the admin panel without touching code.
• Validation: Define public string $api_key in the class; invalid inputs fail fast.
• Tooling: Generate settings classes with php artisan make:setting and migrations with php artisan make:settings-migration.
• Extensible: Override repository() to use Redis for high-traffic settings or custom logic. Example workflow:

1. Create MarketingSettings class with public int $max_discount.
2. Generate a migration to set defaults.
3. Inject into a controller: public function show(MarketingSettings $settings).
4. Update via a form: $settings->max_discount = $request->input('max_discount'); $settings->save();."*