vkn999/eloquentencryption
vkn999/eloquentencryption provides transparent attribute encryption for Laravel Eloquent models, helping protect sensitive database fields at rest while keeping familiar model reads and writes. Configure encrypted attributes and store ciphertext without disrupting application logic.
Architecture fit. The package is a Laravel-oriented library that delegates cryptographic/secure-shell primitives to phpseclib. The v4 line is now explicitly declared compatible with Laravel 9 and PHP 8.0+, which places it in the modern Laravel ecosystem and implies a service-provider/config-publish install pattern with framework-managed singletons or facades. The architectural shape is conventional and low-ceremony, which is favorable for adoption in an existing Laravel codebase.
Integration feasibility. Install is Composer-only and gated by two hard constraints: a PHP floor of 8.0 and an Illuminate major of 9. Both are satisfiable in a current-codebase scenario, but the PHP 8.0 floor means any application still on 7.4 is excluded outright — there is no dual-support path. The phpseclib/phpseclib constraint at 2.0.37 is the more consequential detail: phpseclib 2.x is the legacy maintenance branch, while 3.x is the actively developed line. Any host application with a direct or transitive requirement on phpseclib 3.x will produce an unresolvable Composer conflict, and that is the single most likely blocker in a real upgrade.
Technical risk. Three risks warrant flagging at the assessment level:
Key questions.
^2.0.37 or an exact 2.0.37? The latter would block even patch-level security fixes.Stack fit. The package matches a Laravel 9 / PHP 8.0–8.x application with no competing phpseclib requirement. It does not match applications on PHP 7.4, on Laravel 8 or earlier, or on any dependency graph already resolved to phpseclib 3.x. Confirming the phpseclib constraint shape against our root composer.json is the first gate and should be treated as go/no-go rather than a detail.
Migration path. v4 is a major bump, so treat it as a migration, not an upgrade. The correct sequence is: (1) pin the current v3 (or prior) release and record the working behavior; (2) run composer why phpseclib/phpseclib to determine whether 3.x is already present transitively; (3) if clear, attempt the v4 install in a branch and diff the package's public surface and config file against the prior version; (4) reconcile any config or call-site changes; (5) validate against real credentials and endpoints in staging before merging. Where the host application cannot meet the PHP 8.0 or Laravel 9 floor, the only correct outcome is to remain on the prior major and record the package as a blocker on the framework-upgrade roadmap.
Compatibility. Compatibility is narrow and explicit: PHP 8.0+, Laravel 9, phpseclib 2.x. There is no published evidence of Laravel 10/11 support, so any near-term framework upgrade must be treated as unvalidated against this package. Conversely, the phpseclib 2.x floor should be checked for patch currency — if the constraint permits ^2.0.37, routine patch updates remain available; if it is exact, we inherit a frozen dependency.
Sequencing. Land this package upgrade after the PHP 8.0 and Laravel 9 platform work, and before any move to Laravel 10+, so that each variable is isolated. Do not bundle it with the framework major upgrade; a failure in either would be ambiguous to diagnose. Validate in staging with production-shaped credentials and network paths before production rollout.
Maintenance. The phpseclib 2.x dependency is the dominant long-term maintenance concern. That branch is in security-fix-only mode, meaning we should expect no new features, spotty fixes for newer PHP versions, and eventual abandonment. This package's health is therefore partly hostage to a dependency the maintainer does not control the roadmap for. The Laravel 9 framing compounds this: supporting a framework version that is itself out of bug-fix support implies the package may lag the ecosystem by roughly one major. Budget for periodic re-evaluation rather than a set-and-forget adoption.
Support. Expect community-grade support unless a commercial arrangement exists. Release notes for this major version are terse and do not enumerate breaking changes, which is a signal about documentation thoroughness — we should anticipate reading source or changelogs rather than relying on upgrade guides. Internal ownership should be assigned to a specific engineer rather than left to the team collectively.
Scaling. If the package is used per-request for cryptographic or connection-oriented operations, cost is CPU-bound and latency-sensitive; these calls do not scale horizontally for free. Where usage is confined to background jobs, scheduled tasks, or admin operations, scaling impact is negligible. Establish which pattern applies before sizing. Connection pooling or reuse should be confirmed as supported if the package maintains remote sessions.
Failure modes. Anticipate: Composer resolution failures on phpseclib (loud, caught at build time — the benign case); authentication and key-format failures against remote endpoints; network timeouts and partial-transfer conditions if the package wraps file or shell operations; and configuration drift after the major bump, where renamed keys cause silent fallback to defaults rather than an explicit error. That last category is the dangerous one and argues for explicit config assertions in staging rather than relying on default behavior.
Ramp-up. Low. A Laravel developer familiar with package installation and config publishing can be productive quickly, and the framework conventions reduce onboarding cost. The non-obvious knowledge is concentrated in the phpseclib layer — key formats, cipher negotiation, and host-key verification — so ramp-up for anyone debugging connection-level failures will be materially steeper than for routine use. Plan for one engineer to go deep rather than distributing shallow familiarity across the team.
How can I help you explore Laravel packages today?