Weave Code
Laravel Nova Simple Setting Laravel Package
elipzis/laravel-nova-simple-setting
A simple settings package for Laravel Nova that stores key-value configuration in the database and lets you edit app-wide options, toggles, and site settings from a clean Nova interface—no custom admin screens required.
⚙️Laravel Nova Resource for a simple key/value typed setting
Frequently asked questions about Laravel Nova Simple Setting
- How do I install elipzis/laravel-nova-simple-setting in a Laravel app?
- Install it with Composer, publish the package config and migrations, run the migrations, then register the Nova resource or tool so it appears in your admin panel. The TPM assessment estimates hours, not weeks, for a greenfield Laravel 11 plus Nova install. Before starting, confirm the composer.json constraints on the tagged release you plan to use, since the package is pre-1.0.
- Does this package support Laravel 11, and which Nova versions are compatible?
- Release v0.3.1 is titled Bump Laravel to 11, which points to PHP 8.2+ and Laravel 11, but every changelog entry listed for that release is a GitHub Actions dependency bump, so the Laravel 11 claim is not verified by the published notes. Check composer.json for laravel/framework, php, and laravel/nova constraints on the tagged commit. Nova is versioned separately from Laravel, so confirm the Nova major (4.x or 5.x) in the support matrix, and note that the notes do not say whether Laravel 10 support is retained or dropped.
- How are setting values typed and validated?
- The package stores key/value settings with typed values that you edit through the Nova interface. Because the package is at 0.x, value casting and Nova field behavior should be treated as unstable, and untyped or unvalidated keys invite drift and orphaned records. Add your own validation and a thin application-level accessor rather than relying on the package surface spreading through your codebase.
- Is this package suitable for multi-tenant applications?
- No. The architecture assumes a single settings scope per application, so fit drops sharply for multi-tenant SaaS. Feature flags, branding strings, and contact details for one admin app are a good match; per-tenant settings with isolation requirements are not. For multi-tenant needs, use a first-class domain table with tenant scoping instead.
- Can I store API keys or other secrets with this settings package?
- You should not. Settings stored this way are runtime-mutable and sit outside config caching and deployment review, and plaintext storage of secrets in a key/value table is a recurring failure in this package category. Keep secrets in the environment or a secret manager, and reserve the package for human-editable, non-secret operational values. Encryption at rest and audit trails are not documented in the provided context.
- What belongs in these settings versus config files or .env?
- Use config/ and environment variables for structural configuration and secrets that should go through deployment review. Use the package for operational, non-secret, human-editable values such as feature flags surfaced to admins, branding strings, contact details, and pagination defaults. Wire reads through a thin accessor so you can swap the storage later without touching the whole codebase.
- Are there migration or schema changes between v0.3.0 and v0.3.1?
- No API or schema changes are documented with v0.3.1, and the visible changelog supports a CI-only change. That does not prove the absence of schema edits, so diff the migrations and composer.json between the two tags before upgrading. If you maintain a custom settings table, run the package in parallel, dual-read with backfill, and decommission the legacy table in a later release rather than doing a single-step cutover.
- Is this package production-ready given it is still 0.x?
- Treat it as a convenience layer, not infrastructure. There are no semver guarantees, so a 0.4.0 could break Nova field behavior or the settings schema without a major-version signal, and maintenance posture such as commit cadence, issue backlog, and bus factor should be checked before adoption. It is reasonable for bounded internal admin use if you isolate it behind an accessor and keep a migration path to your own table.
- How do I read these settings from my application code?
- Settings are persisted as key/value records surfaced through the Nova UI, so reads in app code go through the package model or API; the exact helper usage is not documented in the provided context, so check the repository README. Wrap those reads in your own accessor or repository class so a pre-1.0 change does not ripple through your code. Also confirm whether the package caches values, because database-backed settings are read at runtime.
- How does this compare to spatie/laravel-settings or a custom settings table?
- Spatie's package is a broader, non-Nova settings solution that fits when you do not need an admin UI or want stronger typing and caching conventions. A custom table gives full control over tenant scoping, audit trails, and encryption, at the cost of building the admin screen yourself. Choose elipzis/laravel-nova-simple-setting when you already run Nova and want minimal effort for a handful of operational settings.
Weaver
How can I help you explore Laravel packages today?