- How do I install nova-settings in a Laravel Nova application?
- Install the package with Composer, publish its config file and migration, then run php artisan migrate to create the nova_settings table. Register the tool in your NovaServiceProvider::tools() method so the Settings screen appears in the Nova sidebar. Setup is typically a matter of hours for a developer already familiar with Nova. You must have a licensed Laravel Nova installation before this package is usable at all.
- Which Laravel and Nova versions does nova-settings support?
- The package tracks Laravel Nova majors, so you should match the package release line to your installed Nova version (for example Nova 4 versus Nova 5). It is a Nova tool first, which means the Nova major version is the primary compatibility constraint rather than the Laravel version alone. Check the composer.json constraints on the release tag you plan to use before upgrading Nova, because a Nova upgrade can force a package upgrade or a fork. Confirm your required PHP and Laravel versions against those constraints during evaluation.
- How do I define which settings appear in the Nova Settings tool?
- Settings fields are declared using standard Nova field classes, either in the package config or from a service provider. Each field is mapped to a key, and Nova renders that field on the Settings screen, so the editing UI is entirely familiar Nova form UI. Because definitions use native Nova fields, validation is expressed through the field rules you already know. Plan a sane key namespace up front, since the keys become the lookup identifiers in your code.
- How do I read a setting value in my Laravel application?
- Read stored values with the nova_get_setting($key, $default) helper, passing the key and a fallback value. Reads are served from a cached snapshot of the nova_settings table rather than hitting the database on every request. This makes it convenient for operator-editable values like support emails, banner copy, feature toggles, and logo uploads. Do not treat it as a system of record for anything requiring strict consistency on a hot path.
- What happens if a setting key is missing or the settings table is empty?
- The helper accepts a default argument, so the safe pattern is to always supply an explicit fallback for every key you read. You should also decide what happens if the migration has not run yet, since a missing table can surface as a hard failure rather than a silent null. Anything that must remain identical across environments is better kept in config files, with the database setting as an operator override. Document the intended fallback behavior per key rather than leaving it implicit.
- How does nova-settings cache settings, and how is the cache invalidated?
- The package exposes reads through a cached snapshot of the settings table, so changes are not read live from the database on every request. Cache invalidation on write should be verified in your environment rather than assumed. On multi-node deployments without a shared cache store such as Redis or Memcached, nodes can serve divergent values, so a shared store plus a deploy-time invalidation step is strongly recommended. Add a smoke check after deploys that confirms edited settings are visible on every node.
- How does nova-settings store values in the database?
- It writes to a single nova_settings table holding a key column and a JSON-encoded value column. That means no joins, no indexed queries on setting contents, and no database-level constraints or schema validation. Validation lives entirely in the Nova field definitions, so anything written outside the Nova UI bypasses those rules. This simple key-value design is what keeps the package thin, but it makes it unsuitable as a queryable or relational data store.
- Can nova-settings handle multi-tenant or per-tenant settings?
- No, the package has no built-in tenant scoping: it is a single flat key-value store per application. Per-tenant settings would require custom scoping, such as key prefixing or a separate settings row strategy layered on top of the tool. If multi-tenancy is in scope, evaluate whether this package is the right foundation before committing. In many cases a tenant-aware settings package or a custom implementation is the cleaner fit.
- Does nova-settings keep an audit trail of who changed a setting?
- No, there is no versioning, change history, or four-eyes approval workflow, and simultaneous edits resolve as last-write-wins. Access control depends on Nova policies and gates rather than mere menu visibility, so restrictive permissions must be configured explicitly. If settings affect billing, pricing, or access behavior, that gap is a real control risk. For those cases, pair the tool with application-level logging or keep the value in code and deploy it through review.
- Is nova-settings safe for production and how does it compare to alternatives?
- It is MIT licensed, community-supported, and maintained by a single maintainer, with recent releases but no SLA, security response commitment, or commercial backstop, so vendor concentration is the main risk. It is production-reasonable for small volumes of operator-editable settings in a Nova-backed admin, provided you use a shared cache store and verify invalidation. It is not a fit for reproducible, auditable, or schema-validated configuration; spatie/laravel-settings or plain config files are better when you need typed settings, version control, or validation outside the Nova UI. Validate the composer constraints and the fallback behavior for missing keys before adopting it.