Weave Code
Laravel Settings Laravel Package
arcanedev/laravel-settings
Laravel Settings provides a simple, persistent way to manage application settings in Laravel. Store and retrieve settings with database or config drivers, cache support, and an easy-to-use API for global configuration values.
Arcanedev Laravel Settings offers a simple, database-backed solution for managing persistent application settings in Laravel. Store grouped key/value settings and retrieve them through a clean API, with caching to keep reads fast.
- Database storage for grouped settings
- Cache-aware reads and invalidation
- Helper and facade access
- Configurable table and cache options
- Laravel-native integration
Frequently asked questions about Laravel Settings
- How do I install arcanedev/laravel-settings in a Laravel app?
- Install it with composer require arcanedev/laravel-settings. The service provider is auto-discovered, so you then publish the config file and the migration, run php artisan migrate, and optionally seed your default values. After that the setting() and settings() helpers and the Settings facade are immediately available for reads and writes. The whole setup is roughly a 10-minute job on a fresh app.
- Which Laravel and PHP versions does arcanedev/laravel-settings support?
- Do not assume this from the README; read the composer.json illuminate/support and php constraints for the exact release you plan to use. The last tagged release was March 2024, so Laravel 9 and 10 on PHP 8.1+ are the safest bet, while Laravel 11 and 12 or PHP 8.3+ are unverified. Run a compatibility gate by installing into a branch on your exact Laravel and PHP versions and executing your full test suite before committing. Pin an exact version rather than a caret range to avoid a surprise patch breaking things.
- How do I read and write settings with this package?
- Reads use the setting('key', $default) helper or the Settings facade, and writes go through the same facade's set methods before persisting to the repository. The package advertises support for multiple value types such as booleans, integers and arrays, so verify the casting behaviour in your spike rather than storing complex payloads blindly. Because everything sits behind a repository contract, you can wrap the facade in your own SettingsService interface and keep call sites decoupled from the package.
- Does arcanedev/laravel-settings cache settings, and how is the cache invalidated?
- Yes, caching is a built-in feature of the package and is one of its main selling points for runtime configuration reads. What is not clearly documented is whether a write busts the cache globally, per key, or simply leaves entries to expire on TTL. That distinction determines multi-node correctness, so test a write on one app node and a read on a second node during your spike. If invalidation is TTL-only, keep TTLs short or add your own cache-busting hook.
- What storage drivers does the package provide?
- It uses a driver-based repository, with the database driver as the default and a JSON/file driver plus an in-memory array driver as alternatives. The database driver fits any app already running MySQL or Postgres and is the only sensible choice for multi-node deployments. The JSON driver is fine for single-node, low-stakes use but should be explicitly ruled out for containerised or horizontally scaled environments where local files diverge between instances.
- Can I store settings per model, for example per user or per team?
- Yes. The HasSettings trait adds a polymorphic settings() relation to any Eloquent model, so individual records can carry their own overrides on top of global settings. This is useful for per-user or per-team preferences without building a separate table yourself. Watch the row count and indexing on that polymorphic table as it grows, since it can become the largest table in the package's schema.
- How do I migrate existing config files and ad-hoc settings tables to this package?
- Start by inventorying every setting currently living in config/*.php constants or a custom key-value table and classify each one as global or per-model. Create the package schema, backfill the values, then put a SettingsService interface in front of the package so no call site touches the facade directly. Dual-read with fallback to the legacy source for one release before decommissioning the old path. The adapter is your insurance policy: if the package is abandoned, swapping it out becomes a single class change.
- Is arcanedev/laravel-settings production-ready and actively maintained?
- Treat it as a low-evidence dependency: around 73 GitHub stars, zero dependents, a single visible maintainer, no published security policy, and a last release in March 2024. There is no downstream ecosystem to surface regressions and no stated succession plan, so there is real abandonment risk. That does not disqualify it, but it does mean pinning an exact version, wrapping it behind your own interface, and avoiding it where you need a hard support SLA. The DB-backed repository pattern it implements is sound; the maintenance signal is the weak part.
- Does it support encryption for sensitive settings, and what happens on APP_KEY rotation?
- Encrypted settings are not documented in the package overview, so assume they are unsupported until you verify in the source. If you need to store API keys or secrets, encrypt at the application layer before handing values to the repository, or keep those values in the environment instead. If you do roll your own encryption, plan explicitly for APP_KEY rotation, because ciphertext written under an old key will fail to decrypt after a rotation.
- How does it compare to spatie/laravel-settings or just using config files?
- Config files are static and require a deploy or a config cache rebuild to change, which is exactly the problem this package solves. Compared with alternatives, arcanedev/laravel-settings offers a similar database-backed repository, a facade plus helpers, and a HasSettings trait for per-model overrides, but with far less community adoption and production evidence. If you need a widely used, actively maintained option, evaluate a more popular package or a small custom key-value table behind your own interface. Run a one-to-two day spike to prove or kill it against your actual Laravel version before deciding.
Weaver
How can I help you explore Laravel packages today?