- How do I install outerweb/filament-settings in a Laravel app?
- Install it with Composer using composer require outerweb/filament-settings, which also pulls in the underlying outerweb/settings storage package. Publish the settings table migration and config file, run the migration, then register the plugin or settings page in your Filament panel provider. Finally, author one or more settings classes whose schema is expressed as Filament form components so the page knows what to render.
- Which Laravel, PHP and Filament versions does this package support?
- The package is built for Laravel 10 and 11, PHP 8.1 and above, and Filament v3 panels running Livewire. Always check the composer.json constraints in the repository against your pinned Filament version before committing, since a mismatch there is the most likely early blocker. If you are on Filament v2 or an unreleased v4, verify support first rather than assuming compatibility.
- Does outerweb/filament-settings work with Filament v4?
- There is no confirmed Filament v4 path at the time of writing, so treat v3 as the supported target. Because settings schemas are defined using Filament form components, a Filament major upgrade would be both a UI change and a data-model migration. If v4 compatibility matters to you, check the repository issues and commit history before adopting, or plan to fork and adapt the page yourself.
- How do I define a settings class with typed properties and form fields?
- You create a PHP class that declares public typed properties for each setting and a schema method returning familiar Filament form components such as text inputs, toggles, or selects. The admin page renders those components, validates input through Filament, and persists the values to the database using the base settings package. Values are cast back to their declared types on read, so your application code works with real booleans, integers, and arrays rather than raw strings.
- Is the settings page protected by Filament authorization by default?
- Filament pages and resources expose authorization hooks such as canAccess and canView, but you should gate the settings page explicitly rather than relying on defaults. Restrict it to trusted admin roles with a policy or a canAccess check in the plugin registration. Given that settings often include API keys and global behavior toggles, verify who can reach the page in a staging environment before shipping.
- Can settings be scoped per tenant or team for multi-tenancy?
- Per-tenant scoping is not documented as a first-class feature of this thin Filament adapter, so assume settings are global by default. If you need tenant-specific values, you will likely need to extend the base storage layer or wrap it with your own key resolution and scoping logic. Test this early if your panel is multi-tenant, because it affects the schema and migration design rather than just the UI.
- How does caching work and what invalidates cached settings?
- The package includes a read cache for settings values and invalidates it when values are saved through the admin page. Confirm which cache store it uses and whether the invalidation propagates across multiple app nodes and queue workers in your deployment. Also check behavior under config:cache and after programmatic writes that bypass the Filament page, since those may not trigger the same invalidation path.
- Can I store secrets like API keys encrypted at rest?
- There is no documented at-rest encryption layer in this package, so treat the settings table as plain database storage. For sensitive values, either keep them in environment variables and reference them from config, or apply your own encrypted cast and accessor in the settings class. Avoid putting provider secrets into a globally readable settings row unless you have added encryption yourself.
- Can I migrate from spatie/laravel-settings or config() files to this package?
- Yes, the practical path is to model your existing config values or spatie settings entries as typed settings classes while keeping config() as fallback defaults, so behavior is unchanged until a database row exists. Write a one-time seeding or backfill command instead of hand-entering production values through the UI. Access settings through your own repository or facade wrapper so the underlying package can be swapped or forked later without touching call sites.
- Is outerweb/filament-settings production ready and actively maintained?
- It is a small, single-maintainer package with limited stars and few known dependents, so community validation is thin and the bus factor is real. The upside is MIT licensing and a small code surface, which makes fork-and-harden a viable option if the maintainer slows down. Pilot it on one low-risk settings group, such as branding or notifications, rather than on billing or auth-adjacent configuration.