Nova Settings Laravel Package

Product Decisions This Supports

• Unblocks "ops-editable settings" without a sprint. The value proposition is narrow but real: a defined list of non-bootstrap values — mail-from address, support inbox, maintenance copy, integration endpoints, internal feature flags — can be changed by ops or marketing without an engineering deploy. Frame this as a time-to-change win, not a platform capability.

• Frames an honest build-vs-buy call. At 32 stars, zero dependents, and a single maintainer, "buy" is really "borrow with a documented exit." It is defensible only while scope stays small: env-backed scalar fields, trusted internal admin users, staging or local first. The moment settings become customer-facing or multi-tenant, this package is a prototype that informs the real build — not the foundation for it.

• Signals roadmap priority for settings. If settings management is on the roadmap as a product surface (per-tenant config, audit trail, versioning, rollback, approval flow), this tool does not support those decisions. It should trigger a decision to fund spatie/laravel-settings, a custom Nova resource, or a config service — and be treated as a staging convenience in the interim.

• Enables small, high-value feature bets. Feature-flag toggles, kill switches, and copy changes where the requirement is "change without deploy" rather than "store data." Good candidates for an internal rollout experiment where the blast radius is recoverable.

• De-prioritizes engineering work. If this covers staging and internal ops needs, a custom settings CRUD screen can be deferred; that effort is better spent on the parts this package explicitly does not solve — secrets, audit, concurrency.

• Does not support decisions about secrets management, multi-node configuration truth, compliance/audit requirements, or anything read at boot. Those stay with engineering and belong in Vault/SSM/k8s ConfigMaps and the normal config pipeline.

When to Consider This Package

Consider it when:

• You already run Laravel Nova and want an internal admin surface, not a customer-facing one.
• The values are non-bootstrap, non-secret, and recoverable if wrong: mail sender identity, support addresses, maintenance copy, endpoint URLs, internal feature flags.
• Usage is single-tenant and low-concurrency, with a small number of trusted editors who can be gated by a Nova gate or policy.
• Deployment is a single node — or a container setup where .env is genuinely writable and actually the source of truth.
• You run without config:cache in the environments where the tool is enabled, or you have a clear, tested invalidation step in the deploy pipeline.
• The team accepts the maintenance risk: pin the exact version, read src/ before first deploy, and keep the escape hatch open. The contract is narrow ("write env vars"), so the fallback — a ~150-line custom Nova tool — is contained.

Look elsewhere when:

• Any of these appear: multi-tenant settings, customer-facing configuration, approval workflows, versioning/rollback, or an audit/compliance requirement. Use spatie/laravel-settings, a database-backed settings model, or a dedicated config service.
• Secrets management is in scope. .env is not a secrets store; the package's own docs flag write-only Password fields as a classic data-loss trap.
• The values are read at bootstrap (APP_KEY, APP_ENV, APP_DEBUG, DB_*, QUEUE_CONNECTION, LOG_CHANNEL). These must stay out of the UI, or be rendered read-only.
• You run multi-node, read-only filesystems, or platform-injected environment variables. The tool will fail or, worse, create a .env that shadows injected values.
• You need changes to propagate to queue workers, Octane, or the scheduler without manual restarts. Long-running processes cache config at boot; this package does not solve that.
• Nova version compatibility is unverified. Confirm the Nova 4 vs 5 field API against your install before committing.

How to Pitch It (Stakeholders)

To executives: This is a small, low-cost internal tool that lets operations change a curated set of non-critical settings — sender addresses, support inboxes, maintenance copy, internal flags — without booking engineering time for a deploy. It buys back developer hours and shortens the loop on routine copy and configuration changes. It is explicitly not a settings platform: it does not give us audit trails, per-customer configuration, secrets handling, or multi-node consistency. If settings management becomes a product requirement, we will need to fund a proper build, and this should be positioned as a staging-and-ops convenience until then.

To engineering: The integration contract is narrow and the risk is well understood. Settings are declared in a single config file as native Nova fields, and values are persisted to .env. That means: gate the tool behind a Nova gate, enable it in local and staging first, keep bootstrap and secret keys out of the declared fields, and never call env() outside config/*.php — read everything through config(). Verify the save loop end-to-end before adding a second group: check the file was rewritten with quoting intact, check the value resolves in a fresh Artisan process, and check a queue worker after queue:restart. Pin the version exactly (1.1.2), smoke-test on staging after any bump, and keep the exit path in mind — a small custom Nova tool replaces it without touching application code.

The one-line version: A cheap, contained way to stop paging an engineer to change an email address — provided we keep it scoped to internal, recoverable, non-bootstrap values and treat it as borrowed rather than bought.