Filament Db Config Encrypt Laravel Package

Getting Started

This package is a Filament plugin for database-backed settings with encryption and caching, plus a generator for settings/content pages. With 1 star and 0 dependents, treat it as source-available rather than battle-tested — read the source before relying on it.

1. Install

   composer require ngankt2/filament-db-config-encrypt
   

   Confirm it resolves against your Filament major (v3 vs v4) and PHP version before proceeding; a plugin this young often pins a single Filament line.

2. Publish assets and migrations

   php artisan vendor:publish --tag="filament-db-config-encrypt-config"
   php artisan vendor:publish --tag="filament-db-config-encrypt-migrations"
   php artisan migrate
   

   If tags fail, run php artisan vendor:publish without a tag and inspect the provider's publishes() array — tag names in low-adoption packages are frequently inconsistent with the README.

3. Register the plugin in your panel provider:

   public function panel(Panel $panel): Panel
   {
       return $panel
           ->plugin(\Ngankt2\FilamentDbConfig\FilamentDbConfigPlugin::make());
   }
   

   The actual FQCN may differ; check src/ for the plugin class and follow its Plugin interface.

4. First use case: a single "Application Settings" page holding non-secret keys (site name, support email, feature toggles) and an encrypted group for credentials (SMTP password, API tokens). Once that page renders and round-trips a value, you understand the package.

Where to look first: the generated settings page class (how fields map to config keys), the service/repository class that reads values, and the migration (column types tell you whether values are stored JSON-encoded or plain strings).

Implementation Patterns

Group values into named sections/pages. Rather than one giant settings form, create a page per domain (Mail, Integrations, Branding). Each page maps to a config group, keeping forms small and cache invalidation scoped.

Read settings through the package's accessor, not config(). The whole point is DB-backed overrides. Wrap reads in a thin helper of your own so you're not married to the package API:

function setting(string $key, $default = null)
{
    return app(\Ngankt2\FilamentDbConfig\ConfigRepository::class)->get($key, $default);
}

That helper becomes your escape hatch if the package stalls.

Encrypt secrets deliberately. Keep secrets in a separate group from ordinary content. Encrypted values usually can't be queried or sorted in SQL — which is fine for credentials, painful if you accidentally store a toggle or number there.

Cache warm-up in deploy. If the package caches values (it advertises caching), have a post-deploy step that flushes and re-warms it, otherwise your settings page and your app can disagree after a deploy:

php artisan db-config:clear-cache   # verify the actual command name in the service provider

Editable content pages. For CMS-style content, create one page per content type and let non-technical editors manage copy. Keep rendering in Blade components reading the setting helper — don't let the plugin's page classes leak into your frontend layer.

Multi-tenant / environment separation. If your app is multi-tenant, verify whether settings are global or scoped. Most packages of this size assume global — you may need to key values by tenant manually (e.g., prefix keys with the tenant ID) or store per-tenant records yourself.

Testing pattern. Seed settings in test setup via the package's write method rather than editing .env, so tests exercise the same path production does.

Gotchas and Tips

config:cache and encryption. Encrypted values are decrypted with APP_KEY. If you rotate keys without a re-encryption migration, stored secrets become unreadable and may throw rather than fail gracefully. Back up the config table before any key rotation.

Cache staleness after manual DB edits. Direct SQL updates bypass the package's invalidation. Any script that writes to the settings table should call the package's cache-clear (or run the artisan command) afterward. Prefer the package's API over raw DB::table() for exactly this reason.

Migration order. The plugin's migration must run after any users/teams tables if it has foreign keys. If migrate fails on a fresh DB, that ordering is the usual cause.

Filament version drift. A single-maintainer plugin frequently targets one Filament major. Before adopting, check composer.json's Filament constraint against your installed version; a mismatch produces blank settings pages or Method not found errors in the panel rather than a clear exception.

Encrypted fields in Forms/Tables. Encrypted columns are typically text, which Filament renders as a textarea by default — always cast explicitly (->password(), ->revealable()) so secrets aren't shown in plain text in the UI or in Livewire payloads.

Debugging reads. If a value seems wrong, check in this order: (1) the DB row exists, (2) the cache was flushed, (3) the key name matches exactly (case and separators are a common mismatch between form field name and read key), (4) decryption succeeds when reading directly via tinker.

Extension points to lean on. The published config file and the settings page base class are usually the safest customization surfaces. Subclass rather than editing vendor files — with 1 star, you will likely need to patch something, and a fork or a composer patch entry is more honest than inline vendor edits.

Pin the version. Use an exact constraint ("ngankt2/filament-db-config-encrypt": "1.0.3") rather than ^1.0. For a package with this little adoption, an unexpected minor bump is a real risk on composer update.

Have a fallback plan. If the package breaks on a Filament upgrade, the data lives in a normal DB table — you can read it with your own repository and drop the plugin for the UI. Keep the setting() helper thin so that swap takes an afternoon, not a sprint.