- Which Laravel and Filament versions does inerba/filament-db-config support?
- The package requires Laravel 12 with Filament 4 or 5, and the README states these as hard requirements rather than soft suggestions. There is no documented support matrix for Laravel 10 or 11, so legacy applications are effectively excluded. If you are not already on Laravel 12 and a current Filament major, look elsewhere or be prepared to fork. Because Filament ships breaking majors regularly, expect an upgrade window each time Filament releases a new major version.
- How do I install and set up filament-db-config in a Laravel app?
- Install it with composer require inerba/filament-db-config, then publish the migration and config file and run php artisan migrate. After that you can generate a settings page with the make:db-config artisan command and define your form fields. There are no dependencies beyond Laravel, Filament and a JSON-capable database engine. A working settings screen is typically achievable in under a day.
- Can I store API keys or SMTP passwords with DB Config?
- No, you should treat this package as non-secret configuration only. Values are persisted as plain JSON in a database table and cached in your cache store with no field-level encryption. Any API keys, tokens or mail passwords saved here are plaintext at rest and in cache. The README has a security considerations section, but the design itself provides no encryption layer.
- How does caching work in filament-db-config and how do I prevent stale settings?
- Settings are cached with a default ttl of null, meaning they are cached forever. Correctness depends entirely on all writes going through DbConfig::set(), which is what refreshes the cache. Direct database edits, seeders, other services or a second application sharing the database will silently serve stale values. Multi-node deployments are only safe when every node uses the same shared cache store.
- How do I generate an admin settings page with make:db-config?
- Run php artisan make:db-config to scaffold a page class that extends AbstractPageSettings or AbstractWidgetSettings depending on your use case. You then define the Filament form fields on that class and the plugin handles reading and writing the stored values. The generator is non-destructive, so it warns and skips files that already exist and can safely be re-run during iterative development.
- What is the difference between db_config() and safe_db_config()?
- Both helpers read values from the underlying db_config table, but safe_db_config() is designed for boot-sensitive paths where the database or cache may not yet be available. Use it in service providers, middleware and pre-migration contexts to avoid bootstrapping failures. The plain db_config() helper is fine in normal request and page rendering flows. The existence of the safe variant shows the author has considered the most common production failure mode for DB-backed settings.
- Is filament-db-config actively maintained and safe to use in production?
- The package shows an active release cadence with a recent release, but it has a small adoption footprint of roughly 37 stars and no dependents. It is a single-maintainer project with no visible governance, so the bus factor is one. You would be an early adopter rather than a follower, and you should plan for the possibility of forking. For low-risk internal admin settings this is often acceptable, but evaluate it against your own risk tolerance.
- Does filament-db-config support multi-tenant applications?
- Not out of the box. There is no documented per-tenant scoping, per-group access control or environment scoping, and groups are essentially a naming convention rather than an enforced boundary. Multi-tenant products would need custom scoping logic layered on top of the package. If tenant isolation is a hard requirement, a purpose-built or hand-rolled settings table may be a better fit.
- How does DB Config compare to spatie/laravel-settings?
- Both solve the same problem, but spatie/laravel-settings centers on typed settings classes backed by migrations, while DB Config provides a single JSON key/value table with helper functions, a facade and generated Filament admin pages. DB Config's strongest advantage is the make:db-config generator, which standardizes how settings screens are built and reduces bespoke admin code. Spatie's package has broader adoption and a longer track record. Choose DB Config when you are already on Filament 4 or 5 and want ready-made admin UI scaffolding.
- What happens if two admins save the same DB Config page at the same time?
- The generated page saves each top-level key individually when the Save header action runs, and there is no visible optimistic locking or version column. Two admins saving concurrently can therefore silently overwrite each other's changes, a classic lost-update scenario. Similarly, because values are stored as opaque JSON, renaming or removing form fields leaves orphaned values behind with no migration path. Keep the number of simultaneous editors low or add your own locking around sensitive settings pages.