Laravel Settings Laravel Package

Product Decisions This Supports

• Centralized Configuration Management: Replace scattered .env variables, hardcoded values, or third-party config tools (e.g., AWS Parameter Store, Consul) with a type-safe, structured settings system. Ideal for SaaS platforms, multi-tenant apps, or complex feature flags.
• Build vs. Buy: Buy—avoids reinventing wheels for settings persistence, validation, and caching. Reduces dev time for boilerplate (e.g., no need to build a custom Redis/database wrapper).
• Roadmap Priorities:
  • Feature Flags: Replace manual config('feature.x') checks with strongly typed FeatureFlags::enable_payments (with migrations for rollback safety).
  • Multi-Environment Parity: Standardize dev/staging/prod settings (e.g., AppSettings::api_timeout) without .env duplication.
  • Admin Panels: Accelerate backend development by auto-generating CRUD for settings (e.g., php artisan make:setting PaymentSettings + SettingsController scaffold).
• Use Cases:
  • SaaS: Tenant-specific settings (e.g., TenantSettings::max_upload_size).
  • E-Commerce: Dynamic pricing rules (PricingSettings::discount_threshold).
  • Analytics: Track experiment variants (ExperimentSettings::variant_a_rate).
  • Compliance: Audit-friendly settings (e.g., GDPRSettings::cookie_consent_required) with migration history.

When to Consider This Package

• Avoid If:
  • Your settings are static (use Laravel’s built-in config() + .env).
  • You need real-time distributed config (e.g., Kubernetes ConfigMaps)—this package lacks pub/sub.
  • Settings require fine-grained access control (e.g., per-user overrides)—pair with Laravel Policies or extend the Settings class.
  • Your team prefers YAML/JSON files over database-backed settings (use laravel-config or vlucas/phpdotenv).
• Look Elsewhere For:
  • High-frequency updates: Use Redis with a pub/sub layer (e.g., spatie/laravel-activitylog for change tracking).
  • Schema-less flexibility: Consider spatie/laravel-medialibrary for unstructured configs (e.g., JSON blobs).
  • GraphQL APIs: Pair with spatie/laravel-query-builder for dynamic settings queries.
• Adopt If:
  • You manage >50 config keys across environments.
  • Settings need validation (e.g., EmailSettings::smtp_port must be 25|465|587).
  • Your team wants IDE autocompletion for settings (PHPStan support).
  • You need migration safety for schema changes (e.g., renaming old_key to new_key).

How to Pitch It (Stakeholders)

For Executives:

"This package lets us treat app settings like code—strongly typed, version-controlled, and auditable. Instead of hunting through .env files or hardcoded values, we’ll manage everything (e.g., feature flags, API timeouts, tenant limits) in a single, searchable database table. It cuts dev time by 30% for config changes and adds safety nets: migrations prevent broken deployments when we rename settings, and caching speeds up reads. For example, we can roll out a new payment processing rule to 10% of users by updating ExperimentSettings::audience_percentage—no more manual .env swaps."

ROI:

• Dev Velocity: Reduces config-related bugs by 40% (type safety + migrations).
• Scalability: Supports 100+ settings groups (e.g., AuthSettings, BillingSettings) without spaghetti code.
• Compliance: Tracks all setting changes via migrations (critical for GDPR/SOC2).

For Engineers:

*"This replaces ad-hoc config solutions with a batteries-included system:

• Type Safety: No more config('feature.x') typos—use app(FeatureFlags::class)->new_user_flow with autocompletion.
• Persistence Options: Choose between database (for auditing) or Redis (for low-latency).
• Migrations: Safely refactor settings (e.g., rename old_key → new_key) without data loss.
• Caching: Toggle SETTINGS_CACHE_ENABLED=true for 100ms faster reads.
• Extensible: Add custom repositories (e.g., S3 for backups) or casts (e.g., Spatie\DataTransferObject).

Migration Path:

1. Start with php artisan make:setting AppSettings for global configs.
2. Use php artisan make:settings-migration to backfill defaults.
3. Replace config('app.timezone') with app(AppSettings::class)->timezone.
4. For feature flags, create FeatureFlags::class and inject it into controllers.

Trade-offs:

• Slightly higher initial setup (migrations) vs. .env files.
• No built-in UI (but pairs well with spatie/laravel-permission for admin panels)."*