Nova Settings Tool Laravel Package

Technical Evaluation

What this package actually is. weslal/nova-settings-tool is a Laravel Nova tool — not a general-purpose settings library. It registers a Nova tool (service provider, tool routes, compiled Vue assets) that exposes a UI for editing database-backed key/value settings whose groups and fields are declared in application code. The value proposition is narrow but real: admins edit runtime configuration without touching .env or config files, and developers retain a code-level contract for what settings exist.

Architecture fit. Good only under a specific precondition: the application already runs Laravel Nova. Nova is a first-party but paid, closed-source product with per-site licensing and a history of breaking tool APIs between major versions (Nova 1/2 → 3 → 4 → 5). This package's last release is December 2018, which places it in the Nova 1.x era — roughly Laravel 5.7/5.8 and PHP 7.1–7.3. That is the central architectural fact: the package is coupled to a proprietary, fast-moving host, and it stopped moving seven-plus years ago.

Integration feasibility. Mechanically trivial — composer require, register the tool in NovaServiceProvider::tools(), publish/run migrations, declare a settings schema. Practically, feasibility is gated on composer.json constraints resolving against our Laravel, PHP, and Nova versions. On PHP 8.1+ and Nova 4/5, expect a hard conflict; the resolution work is a fork-and-modernize effort (Nova 4+ tool API, Vue 3 asset pipeline), not a configuration change.

Technical risk: high.

• Abandonment. 8 stars, single patch release in the visible history, no evidence of maintainer activity since 2018. Treat as unmaintained vendored code from day one.
• No security triage path. Settings tables commonly hold API keys, SMTP credentials, and feature flags. Storing these as plaintext DB rows written through an admin UI needs encryption, validation, and an audit trail — none of which we can assume this package provides.
• Cache correctness. Database-backed settings read per-request are a query and a latency tax; the correct pattern is cache-on-read with invalidation on save. Whether this package does that, and does it correctly, is the single biggest functional question.
• Documentation quality. Note that the internal assessment artifact circulating for this package describes it as an HTTP middleware component and discusses v1.0.3 as a middleware bug fix. That is a mischaracterization of a Nova tool. Do not carry that assessment forward; re-baseline from the source.

Key questions for the spike.

1. What are the exact require constraints for laravel/nova, illuminate/*, and PHP — and which Nova major do they resolve to?
2. Does it cache settings, and how is the cache invalidated on save? Is invalidation safe across multiple app servers?
3. What field types are supported (text, boolean, select, file, encrypted/secret)?
4. Are writes audited — who changed what, when, with what prior value?
5. Is there a permission/authorization gate beyond Nova's default tool access?
6. How are settings schema changes versioned when a code-declared field is renamed or removed — does the stale DB row get orphaned?
7. Is there any validation layer preventing an admin from setting a value that bricks the app (bad base URL, zero page size, malformed JSON)?

Verdict. Do not adopt as a dependency. Evaluate as a reference implementation or a fork candidate, and benchmark it against spatie/laravel-settings (code-defined settings classes with typed properties and migrations) plus a thin custom Nova resource. That combination is maintained, PHP 8-compatible, and removes the coupling between our settings storage and a 2018 Nova tool API.

Integration Approach

Stack fit. Laravel + Nova on PHP 7.x: viable as-is, with a fork pinned into our repo. Laravel + Nova 4/5 on PHP 8.2+: not viable without a rewrite of the tool's frontend and route registration. Laravel without Nova: not applicable — do not pull a Nova license to obtain key/value settings.

Migration path (recommended).

1. Spike branch, timeboxed to 2–3 days. Install against a throwaway Nova app at our target versions. Outcome is a go/no-go on native use, plus a diff list of what a fork would require.
2. Decision fork. Either (a) fork and modernize — budget 1–2 sprints plus permanent ownership, or (b) implement settings via spatie/laravel-settings with a custom Nova resource for the admin UI — budget roughly the same for the UI, materially less for the storage layer.
3. Extract the schema contract first. Whichever path, define settings as typed code-declared classes with defaults, then generate the admin surface from that contract. This is the durable asset; the UI is replaceable.

Compatibility checks before committing. composer.json constraints versus our Laravel/PHP matrix; Nova tool asset publishing and nova:publish behavior after a Nova upgrade; migration filenames colliding with existing tables; the settings table name being hardcoded.

Sequencing for a production rollout.

1. Schema/contract definition and defaults seed migration.
2. Storage layer + cache with explicit invalidation on write.
3. Access layer — a Settings facade or repository injected into services; never raw DB queries from controllers or Blade.
4. Admin UI behind a Nova permission gate, restricted to a named operator group.
5. Validation rules per field, enforced server-side, not only in the Vue form.
6. Audit log (user, timestamp, field, old value, new value) written in the same transaction as the update.
7. Read-only shadow period: settings editable but consumed only by non-critical paths, then expand.

Do not sequence this as "install and let admins in." The blast radius of a mis-set global setting is the whole application; validation and audit must land before the first human writes through the UI.

Operational Impact

Maintenance. Effectively 100% self-owned. There is no upstream to patch, no release cadence to track, no compatibility work being done for us. If we fork, assign a named owner and add the fork to the dependency-review list; if we vendor, pin the commit and document the delta from upstream. Either way, the total cost of ownership exceeds the cost of the maintained alternative.

Support. No maintainer responsiveness to rely on. For an internal admin tool the support burden is low-frequency but high-severity: when it breaks, it breaks during a Nova upgrade or a PHP upgrade, and it breaks silently (tool disappears from the nav, routes 404) or loudly (settings page 500s). Plan for a fix-forward capability, not a support contract.

Scaling. The package itself is not a scaling concern — the settings table is tiny and write traffic is human-paced. The concern is read amplification: if settings are fetched from the database on every request, that is one extra query per request across every web node and queue worker. Mandate cache-on-read (Redis or the config cache) with invalidation on save, and verify invalidation correctness on a multi-node deployment — a stale-cache bug here presents as "the admin changed it and nothing happened," which erodes trust in the tool fast. If secrets are stored, encrypt at rest and confirm they never land in logs or in the cache in plaintext.

Failure modes.

• Stale cache across nodes — setting appears saved but old value persists on some workers.
• Missing setting — code declares a key, DB row absent (fresh environment, partial seed); returns null and throws deep in a request path.
• Schema drift — code renames a field; the old row persists as dead data and the new field silently defaults.
• Admin-induced outage — a valid-format but operationally wrong value (base URL, mail host, feature flag) takes down a user-facing path. Requires per-field validation, a confirmation step for high-risk keys, and a documented rollback (previous-value audit log is the rollback mechanism).
• Nova upgrade breakage — tool assets or routes stop resolving; no upstream fix exists.
• Credential exposure — plaintext secrets in the settings table flowing into database backups and read replicas.

Ramp-up. Low for a Laravel developer familiar with Nova — a day to understand the tool, perhaps two to understand the fork. The real onboarding content is not the package but our conventions around it: the settings contract, the cache invalidation path, the permission model, and the audit/rollback procedure. Write those down as a short internal runbook before the first operator gets access, because the package will not document them for us.