Weave Code
Config Laravel Package
illuminatech/config
Laravel package for editable application configuration. It lets you override config-file values at runtime and persist settings in the database, so you can build admin panels where application settings are changed without redeploying or editing files.
Manage Laravel configuration by persistent storage
Frequently asked questions about Config
- How do I install illuminatech/config in a Laravel application?
- Install the illuminatech/config Composer package, register its service provider, and publish the package migration and config. Then configure or subclass the config model, whitelist the keys that may be edited, and attach validation rules. The hard part is not installation but defining which keys are database-managed versus code-owned and how they are validated and scoped.
- Does illuminatech/config support Laravel 10, 11, and 12?
- The package predates recent Laravel and PHP releases, so do not assume support for Laravel 10 through 12 or PHP 8.2 and 8.3. Verify the support matrix explicitly and run a compatibility spike on a branch before committing. Budget for patching or a vendored fork if upstream compatibility lags.
- How does illuminatech/config interact with config:cache and Laravel Octane?
- The package overlays database-persisted values on top of config/*.php values at bootstrap, and those values are cached. Under Laravel Octane, long-lived workers can hold stale values unless every write explicitly invalidates the cache. Treat configuration as boot-cached and prove invalidation behavior in testing before production.
- What happens if the database is unavailable during bootstrap?
- illuminatech/config performs a database read during bootstrap, mitigated by caching, so cold-start and cache-flush behavior matter. You must prove whether the application fails open to file defaults or fails closed when the database is unreachable. Also test deployments with a flushed cache and read-replica topologies where bootstrap may hit a lagging replica.
- Which configuration keys should I make editable with illuminatech/config?
- Use it for low-churn global settings such as admin-editable limits, feature toggles, integration credentials, marketing copy defaults, and per-environment knobs. Avoid high-cardinality or per-request state such as user preferences and large per-tenant feature matrices. Start with a small whitelist of non-critical keys and expand only after validation, audit, and encryption controls are in place.
- Can I use illuminatech/config for multi-tenant settings?
- It is a poor fit for per-tenant feature matrices at scale because tenant scoping increases cache key cardinality and complicates invalidation. If you use it for tenants, define the scoping model, cache keys, validation, and ownership policy first. The package supplies the mechanism, but the product policy for tenant configuration is yours to design.
- How should I handle secrets and encryption with illuminatech/config?
- The package provides a persistence mechanism, not a secrets policy, so do not store plaintext credentials in the configuration table. Design encryption at rest, key rotation, access control, validation, and an audit trail before enabling writes. Decide who can edit secrets and how changes are approved and rolled back.
- Is illuminatech/config safe for production given its license and maintenance?
- The license is reported as NOASSERTION, which is a hard legal gate that must be resolved in writing before production. The project has about 149 stars and likely a single maintainer, so assume you own patching and Laravel-version compatibility. Budget for a vendored fork and clarify who owns it if upstream stalls.
- How do I test illuminatech/config, including fresh installs and cache invalidation?
- Run a controlled compatibility spike on a branch with a small whitelist of non-critical keys. Exercise the migration, validation, cache invalidation, Octane behavior, and the table-missing fresh-install path. Then deploy in read-only shadow mode, comparing database values against expected file values in logs before enabling writes for one pilot screen or artisan command.
- When should I avoid illuminatech/config or consider alternatives?
- Avoid it for serverless or edge runtimes, stateless bootstraps where a database round-trip is undesirable, queue-only workers, and high-cardinality per-request or per-tenant state. A custom settings table, file and environment configuration, or a dedicated feature-flag service may fit those cases better. Use illuminatech/config when you need low-churn, globally scoped, runtime-editable Laravel configuration with a database override layer.
Weaver
How can I help you explore Laravel packages today?