Weave Code
Configuration Bundle Laravel Package
sherlockode/configuration-bundle
A Symfony bundle for database-backed application configuration. Define typed settings, manage them through an admin-friendly interface, and retrieve values easily in services, controllers, and templates, with Doctrine persistence and caching support.
Symfony bundle for user-defined configuration values
Frequently asked questions about Configuration Bundle
- Is sherlockode/configuration-bundle a Laravel package?
- No. It is a Symfony bundle with no Laravel service provider, facade, publishable config or migrations, and no extra.laravel block in its composer.json; its integration surface is Symfony's DI container, Doctrine ORM, and Symfony console and event hooks. For a Laravel application it is useful as a reference implementation of the pattern, not as a Composer dependency.
- Can I install sherlockode/configuration-bundle in a Laravel app with Composer?
- Composer may resolve it, but nothing will wire it up: the bundle's services and Doctrine mappings never register without Symfony's kernel. Pulling the entity and manager classes across would also mean running Doctrine alongside Eloquent, adding a second ORM for no feature gain. Unless your application already runs Doctrine, treat it as uninstallable in Laravel.
- What does Sherlockode ConfigurationBundle actually do?
- It stores application settings in the database so they can change at runtime without redeploying, and exposes them through a typed API. Configuration definitions live in code, including types, defaults, validation and grouped sections, while the values live in a Doctrine-persisted table. A single manager service retrieves values in Symfony services, controllers and Twig templates, with cache-friendly access for production.
- Which Symfony and PHP versions does ConfigurationBundle support?
- As of v0.8.0 it targets Symfony 6.4 LTS and 7.x on PHP 8.2 through 8.4, with Composer constraints hardened in that release. That release is a de facto compatibility break for Symfony 5.4 and PHP 8.1 or earlier consumers. Treat v0.8.0 as the viable floor for any Symfony use.
- What is the Laravel alternative to sherlockode/configuration-bundle?
- Benchmark spatie/laravel-settings first, since it occupies the same space natively in Laravel and a maintained package usually beats a reimplementation. Only build your own if its settings-class and migration model does not fit your typed-definition requirements. The bundle's core idea, schema declared in code and values persisted in the database, maps directly onto that package or a small in-house service.
- How would I implement database-backed typed settings in Laravel?
- Model your configuration definitions as a PHP registry or one class per settings group, with types, defaults and validation declared in code, and persist only the values in an Eloquent model or key/value table. Front it with a single injectable settings service that reads through Laravel's cache and invalidates on write, then resolve it from the container in controllers, jobs and Blade views. The effort is days rather than weeks and adds no new runtime dependency. Keeping the schema in code makes misconfiguration fail fast instead of silently returning strings.
- Is it fast enough for production, and how does the caching work?
- The bundle is built for cache-friendly access so configuration reads do not hit the database on every request. In a Laravel reimplementation the equivalent is caching resolved values in Laravel's cache store and flushing the relevant keys whenever a setting is saved. Watch for cache invalidation across multiple servers if you rely on a per-node file cache.
- Can I store API keys or secrets in the configuration table?
- No. A database-backed configuration table is the wrong home for credentials, and the package makes no claim otherwise. Keep secrets in environment variables or a dedicated secret manager and define an explicit allowlist of which settings domains may move into the dynamic store. Review that allowlist with whoever owns security before launch.
- Is sherlockode/configuration-bundle stable enough for production?
- It is pre-1.0 at v0.8.0, with roughly 31 GitHub stars and a single maintainer, so community signal is thin. Semver permits breaking changes on minor bumps in the 0.x range, and the maintainer's roadmap is explicitly Symfony-native. It is reasonable inside a Symfony 6.4 or 7 application on PHP 8.2+, but it is not a dependency to add to a Laravel product.
- What is the exit plan if the bundle or its maintainer disappears?
- Exit cost is low if you borrow the pattern rather than depend on the package, which is the strongest argument for reimplementing it. If you do install it, be prepared to fork it, vendor the code, or migrate to a Laravel-native implementation later. Avoid letting the bundle's manager API leak into your domain code so that a swap stays contained.
Weaver
How can I help you explore Laravel packages today?