Weave Code
Laravel Options Laravel Package
appstract/laravel-options
Store and retrieve global key-value options in Laravel with a simple option() helper and Options facade. Values persist in a database table, support caching for fast access, and can be easily typed, making site-wide settings manageable without touching config files.
Global key-value store in the database
Frequently asked questions about Laravel Options
- How do I install appstract/laravel-options in a Laravel app?
- Require the package with Composer, publish its migration (and optionally its config file) using vendor:publish, then run php artisan migrate to create the options table. After that you can read and write values with the option() helper or the Options facade, for example Option::get('key') and Option::set('key', 'value'). Integration is low effort: no external services, queues, or workers are involved. Most teams can wire it up and wrap it in a repository within a day.
- Is appstract/laravel-options safe for storing secrets or API keys?
- No. Options are stored as plaintext in a database table with no encryption, no change history, no actor attribution, and no per-key access control, so any code path in your application can read or overwrite any key. Secrets belong in environment variables, config files excluded from version control, or a dedicated secret manager. Use this package for operator-controlled settings such as feature toggles, banners, throttle thresholds, and business copy, not credentials.
- Does appstract/laravel-options cache option values, and how do I avoid stale settings?
- Yes, reads are cache-backed to keep option lookups fast, which means writes must invalidate that cache across every node. Verify the invalidation behavior with your actual cache store (for example Redis) and with config:cache enabled, since stale settings after a deploy are the most likely production incident with this package. If you run multiple app servers, test a write on one node and a read on another before relying on it. Wrapping access in your own repository gives you a single place to add explicit cache clearing.
- Can I store arrays, booleans, or null values with laravel-options?
- Values are persisted through JSON serialization, so arrays, booleans, and null are representable, but the exact round-trip semantics should be pinned down before you depend on them. Silent type drift, where a value comes back as a string instead of a boolean or array, is a common source of bugs. A thin typed wrapper that casts and validates on read and write is the practical fix. Decide up front which types each key is allowed to hold.
- Does appstract/laravel-options support per-user or per-tenant settings?
- No, it is a global key-value store intended for application-wide options, not per-user preferences or tenant-scoped configuration. If you need scoping by user, team, or tenant, this is the wrong primitive and you should model those settings as Eloquent records or use a purpose-built multi-tenant settings package. Keeping the global store global also prevents it from turning into an unowned schema that mixes concerns.
- Which Laravel and PHP versions does appstract/laravel-options support?
- The package is maintained by a small vendor with infrequent releases, so check its Composer constraints against your current and next major Laravel and PHP versions before committing. Pin the exact version in composer.json rather than using a loose constraint. Also confirm the published migration's column type works on your database, whether MySQL, Postgres, or SQLite for tests. Testing the install on a throwaway branch is faster than discovering a constraint conflict during a framework upgrade.
- How do I test code that uses the Options facade or option() helper?
- Confirm that the facade is fakeable or stubbable in your test suite, and if it is not convenient to do so, wrap access in your own SettingsRepository interface so tests can swap in an in-memory implementation. Run your test suite against SQLite to catch migration and JSON column differences. Because the package exposes a very permissive global API, a wrapper also lets you assert that only allow-listed keys are written during tests.
- What are the alternatives to appstract/laravel-options for Laravel settings?
- Common alternatives are spatie/laravel-settings, which gives you typed settings classes with strong casting and validation, plain config files and environment variables for values that never change at runtime, or a hand-rolled settings table if you need audit trails and per-tenant scoping. Choose based on whether you need typing, change history, encryption, or scoping rather than raw simplicity. appstract/laravel-options wins when you want the smallest possible global key-value layer with a helper and facade.
- Is appstract/laravel-options actively maintained enough to depend on in production?
- It has roughly 728 stars, a small vendor organization, and infrequent releases, so treat it as adopt with a fork option rather than adopt and forget. Pin the exact version and make sure someone on your team could fork and patch it if upstream goes dormant. Because the surface area is small, an internal wrapper makes a future swap to another package or an in-house table inexpensive. Review the repository's recent commit activity before standardizing on it.
- How does laravel-options handle concurrent writes to the same key?
- Writes are last-write-wins with no optimistic locking, so simultaneous updates can silently overwrite each other. That is acceptable for human-edited settings such as a maintenance banner or integration ID, but it is not suitable for high-frequency automated writes. If automation needs to change values, route those changes through a single job or command to serialize them. Otherwise keep the keys automation touches separate from the ones people edit.
Weaver
How can I help you explore Laravel packages today?