Weave Code
Settings Laravel Package
orchid/settings
Orchid Settings is a Laravel package for the Orchid Platform that provides an admin settings screen for managing application configuration values without code changes. It offers a simple API for storing and retrieving settings, making runtime configuration easy to maintain.
Settings this is key-value storage
Frequently asked questions about Settings
- How do I install orchid/settings in a Laravel application?
- Install it with composer require orchid/settings, then publish the package's config file and migration using vendor:publish and run php artisan migrate. That creates a single key/value table plus the published configuration. After that you can read and write settings through the facade or the global setting() helper, and if Orchid Platform is installed, the admin settings screen becomes available. Total time to a first working value is measured in hours, not sprints.
- Does orchid/settings require the Orchid Platform to work?
- No. The core of the package is a plain Laravel service provider, config file, migration, Eloquent model, and a get/set API with a facade and helper. The Orchid CRUD admin screen is an optional layer that only adds value if Orchid Platform is already in your stack. If you are not running Orchid, you are essentially adopting a key/value table you could write yourself in a day.
- How do I store and retrieve a setting with orchid/settings?
- The API surface is deliberately small: effectively get and set, exposed through a facade and a global setting() helper. You call set to persist a value into the key/value table and get to read it back, with caching handled behind the API. Because keys are untyped and there is no schema, you should maintain your own key registry so nobody loses track of which keys are live.
- Does orchid/settings support per-tenant or per-user settings?
- No. Scope is global only, with no per-tenant, per-user, or per-entity dimension built in. Any multi-tenancy has to be simulated with an application-side key-prefix convention layered on top, which quickly degrades both the admin screen and any dump or audit operations. Treat these values as app-wide configuration, not as a domain model, and pick a different tool if tenant-level variation is coming within twelve months.
- Which Laravel and PHP versions does orchid/settings 5.0.0 support?
- The 5.0.0 changelog is a one-liner stating support for Laravel 9, so it is not an authoritative compatibility statement. Run composer why-not orchid/settings 5.0.0 to get the real PHP and illuminate/* constraints for that tag before you commit. Because 5.0.0 is a major bump with an undocumented diff, also review the changes to storage format, config keys, cache-key format, and helper signatures yourself.
- How does orchid/settings handle caching and cache invalidation?
- The package caches values and invalidates them when writes go through its own API, such as the facade's set method. Direct writes that bypass the API, including seeders, imports, or manual SQL against the table, will serve stale values until the TTL expires. In multi-node deployments invalidation only propagates if you use a shared cache store like Redis or Memcached, since per-node file or array caches will drift.
- Is orchid/settings safe to use in production?
- It is adoptable as a narrow, replaceable configuration substrate rather than a platform bet. The package has a single maintainer, zero dependents, and no SLA, so abandonment would leave you with an unpatched dependency. Mitigate by wrapping it in your own service class so the dependency stays swappable, and record the decision with an explicit exit plan. Also keep entitlement, pricing, or access-control keys behind your wrapper with a hardcoded or config fallback.
- What is the difference between the setting() helper and the facade in orchid/settings?
- Both expose the same underlying get and set behavior; the helper is a convenient global function and the facade is a class-based entry point. The global setting() helper can collide with an identically named function in your application or another package, which results in a fatal redeclaration error. If that happens, use the facade instead, and route all writes through a single wrapper so cache invalidation always fires.
- Does orchid/settings validate values or keep an audit log?
- No. There is no validation, type coercion, audit trail, or approval workflow, so settings become an ungoverned operator surface once the admin screen is live. Values coming from HTML forms are especially risky, since the string "false" is truthy and will silently flip behavior with no error raised. Plan to own a key registry, coercion and validation at the form boundary, and a change log on your side, and budget three to five times the integration cost for that work.
- What are the alternatives to orchid/settings for Laravel configuration storage?
- If you are already running Orchid Platform, the published admin screen is the real business case and adoption is easy to justify. If you are not, consider spatie/laravel-settings for typed settings classes, or simply write your own key/value table and wrapper service in a day. Either way, put a service layer in front so the package is replaceable, and treat it as app-wide configuration rather than a domain model.
Weaver
How can I help you explore Laravel packages today?