Weave Code
Laravel Settings Laravel Package
padosoft/laravel-settings
Laravel Settings gives your application a simple, persistent key-value store for configuration. Define settings in the database, read and update them through a clean API, and rely on caching so values load fast without extra queries. Settings stay editable at runtime, keeping configuration out of co...
Persistent settings with caching in Laravel
Frequently asked questions about Laravel Settings
- How do I install and set up padosoft/laravel-settings in a Laravel application?
- Install it with Composer, then publish and run the package migrations so the settings table exists. Publish the config if you need to define encrypted keys or keyring options, and clear cached config after changes. Check the package's composer.json for the exact Laravel version constraints supported by your release.
- How does caching work in Laravel Settings and will it reduce database queries?
- Laravel Settings stores values in the database but reads through a cache so repeated lookups do not hit the settings table every time. That keeps runtime configuration fast while still letting you edit settings persistently. After changing settings or deploying a new version, make sure the cache is refreshed or versioned correctly so stale values are not served.
- What is encrypted_keys in padosoft/laravel-settings and how does v7 encryption work?
- encrypted_keys is an allowlist of setting keys whose values should be encrypted at rest. In 7.0.0 encryption is handled by a single SettingsCipher component used by both the model and the settings manager. Encrypted values use an envelope format like pdsenc:v1:kid:payload, bound to the setting key and a deployment context so copied ciphertext will not decrypt elsewhere.
- Do I need to run encryption-migrate when upgrading from 6.x to 7.0?
- Yes, if you ever populated encrypted_keys, treat the encryption-migrate command as mandatory rather than optional. Version 6.x could write a mix of single-layer, double-layer, and plaintext-fallback rows, and the command is the intended remediation. Rehearse it on a production-shaped copy before running it in production.
- Why do settings fail to decrypt after deploying to staging or production?
- Version 7 binds encrypted envelopes to a deployment context, so a value encrypted in one environment may not decrypt in another. If staging and production share a database, or a DR region uses a different context value, reads can fail. Confirm how the context is configured and how it behaves during regional failover before rollout.
- What does encryption-audit do and should it gate my rollout?
- encryption-audit checks for allowlisted keys stored in plaintext, and the package fails closed when it finds them. On a database upgraded from 6.x, plaintext rows are a predictable state, so an unaudited deploy can break reads of settings. Run the audit and resolve findings before enabling encrypted settings in production.
- How can I rotate the settings encryption keyring without re-encrypting everything at once?
- The keyring supports previous keys, which enables a two-phase rotation rather than a single all-at-once rewrite. Add the new key, keep the old key available for decryption, then re-encrypt or migrate values in a controlled step before removing the old key. If the keyring is read from config, remember that config:cache bakes it into bootstrap/cache, so rotation needs a config rebuild and a plan for long-lived processes.
- Why did Laravel Settings 7.0 change settings.value to TEXT and what migration risks should I check?
- Encrypted envelopes do not fit in VARCHAR(255), so the value column must become TEXT. On a large settings table this can be a table copy rather than an in-place change depending on MySQL version and row format. Also verify that no existing index or unique constraint covers value, because TEXT cannot be indexed without a prefix length and the migration could fail or change index semantics.
- Does Laravel Settings work with queue workers, the scheduler, and Laravel Octane?
- Yes, but the new v7 keyring is a separate secret from APP_KEY and must reach every process that reads encrypted settings. That includes queue workers, the scheduler, and long-lived processes such as Octane workers that may cache the keyring in memory. Decide up front where the keyring lives and how it is distributed and refreshed across nodes.
- How do I avoid stale cached settings after upgrading to Laravel Settings 7.0?
- Version 6.x could write plaintext values to Redis on cold-cache paths, and those entries can outlive the deploy. Make cache flushing or cache versioning part of the upgrade runbook rather than an afterthought. Verify reads after cutover so old cached values are not served in place of encrypted envelopes.
Weaver
How can I help you explore Laravel packages today?