- How do I install ngankt2/filament-db-config-encrypt in a Laravel app?
- Install it with Composer using composer require ngankt2/filament-db-config-encrypt, then register the service provider if it is not auto-discovered. You will usually need to publish and run the package migrations that create the settings and content tables, then register the Filament page or resource so administrators can edit values. Check the Composer constraints for PHP, Laravel, and Filament first, because this is an early-stage package with limited documentation.
- Which Laravel, PHP, and Filament versions does this package support?
- The repository metadata does not clearly state supported Laravel, PHP, or Filament versions, so treat compatibility as unverified until you read composer.json. Compare those constraints against your host application and test in a non-production branch before committing. If you run an older Filament major version or an unusual PHP version, expect to validate or patch the constraints yourself.
- What exactly gets encrypted in this package: setting values, content pages, or everything?
- The package name and blurb suggest sensitive configuration values are encrypted at rest, but the description does not explicitly say whether entire payloads, individual fields, or content pages are encrypted. Inspect the source or write a test that dumps the raw table columns to confirm which ones contain ciphertext. Do not assume secrets, authorization flags, or editable content are protected until you verify the implementation.
- Is key rotation supported, and what happens to existing encrypted values after rotation?
- Key rotation is not documented, and it is the most important question to answer before storing production secrets with this package. If it relies on Laravel's encrypter, rotating APP_KEY without re-encrypting existing rows will make those values unreadable. Plan a re-encryption migration, test it against a copy of production data, and confirm rollback behavior before relying on rotation.
- How does caching work for database-backed settings in this package?
- The overview mentions caching, but the cache driver, TTL, warm-up strategy, and invalidation semantics are not described in the available metadata. In a multi-node deployment you must confirm whether invalidation propagates across nodes or whether each node can serve stale values. Test with your real cache driver, such as Redis, database, or file, and consider wrapping reads in an internal repository you control.
- How do I read settings in application code outside the Filament admin panel?
- The package is described as a Filament plugin, so the admin UI is the primary surface, but application code usually needs a helper or facade to read values. Look in the source for a documented API or a service you can resolve from the container. If none exists, create a thin SettingsRepository abstraction so call sites do not depend directly on package internals and you can swap the implementation later.
- Can I use this package for multi-tenant applications?
- Multi-tenancy is not evidenced in the package metadata, so assume it is out of scope unless you confirm otherwise in the source. Teams needing per-tenant settings typically add a tenant column, scope queries, and enforce authorization themselves. If tenant isolation is a hard requirement, plan to fork the package or wrap it behind your own tenant-aware settings repository.
- Does editable content support sanitization and protect against stored XSS?
- Editable content rendered through Filament or Blade can introduce stored XSS if output is not escaped or sanitized, and the package metadata does not describe sanitization rules, draft and publish workflows, or editor authorization. Enforce escaping in your templates, sanitize rich text with a library such as HTML Purifier, and restrict who can edit content. Review the rendering path in the source before exposing content editing to non-technical users.
- Is this package safe to use in production?
- Treat it as an early-stage component: the repository has negligible adoption, a single maintainer, and undocumented security, cache, and migration behavior. It can be acceptable for low-risk administrative settings in a monolith where you control deployment and rollback. Avoid using it for secrets, authorization-critical flags, or regulated data until encryption, key management, schema migration, decryption failure fallback, and audit behavior are verified.
- What are the alternatives to this package for encrypted Laravel settings?
- Alternatives include spatie/laravel-settings for typed, class-based settings, and plain config files plus environment variables for values that rarely change. For encrypted values you can store ciphertext in your own table and decrypt through Laravel's Crypt facade. The right choice depends on whether you need a Filament editing UI, runtime editability, or strict security and audit guarantees.