Laravel Encryptable Laravel Package

Product Decisions This Supports

• Compliance and data-at-rest features: transparently encrypting Eloquent attributes (PII, health data, financial identifiers, API tokens) is a recurring requirement in GDPR/CCPA/HIPAA-adjacent roadmaps. This package lets that land as a schema/cast change rather than a re-architecture.
• Searchable encryption use cases: supports querying on encrypted columns (equality-style lookups via a deterministic hash companion value), which unblocks features like "find customer by email" or "look up record by SSN fragment" that naive encryption would otherwise force into application-side filtering or a separate search index.
• Build vs buy: buying here is cheap — a small trait + cast layer replaces in-house crypto plumbing that typically accumulates key-rotation bugs, inconsistent IV handling, and ad-hoc Crypt::encryptString calls scattered across services. Prefer this over bespoke encryption unless you need field-level access policies or searchable range queries.
• Roadmap sequencing: the 4.1.0 release (Laravel 13 / PHP 8.5 support) is a signal that adopting it does not pin the platform upgrade roadmap. That matters when planning a framework upgrade quarter — you can schedule Laravel 13 without an encryption-layer migration project.
• Scoping guardrail: the same release confirms the package is in maintenance mode rather than feature-expansion mode. Do not plan roadmap bets on new capabilities (key rotation tooling, per-tenant keys, range/prefix search) arriving from upstream; budget those as internal work if required.

When to Consider This Package

Consider adoption when:

• You have a small-to-medium set of sensitive scalar columns on Eloquent models (names, emails, phone numbers, government IDs, tokens) and want encryption applied consistently at the model layer.
• Your access pattern is exact-match lookup on encrypted fields. This is the package's sweet spot; anything else is a mismatch.
• You are on, or planning, current Laravel and PHP versions — 4.1.0 explicitly supports Laravel 13 and PHP 8.5, which is the main substantive change in this release.
• You want minimal operational surface: no external KMS integration required to get started, keys come from Laravel's existing APP_KEY/config.
• You need it to coexist with existing $casts and incremental rollout — you can encrypt one model at a time rather than doing a migration big-bang.

Look elsewhere when:

• You need range, sorting, prefix, or LIKE queries on encrypted data. Deterministic hashing gives equality only; ordering and partial matching will require a different design (application-level indexing, a search service, or a purpose-built searchable-encryption product).
• You need per-tenant or per-user key management, envelope encryption, or KMS/HSM-backed keys with rotation SLAs. That is not this package's job, and the maintenance-only release cadence suggests it will not become that.
• You are on an older Laravel/PHP combination and cannot upgrade — check the version constraints before committing, since the newest release targets the modern end of the matrix.
• Threat model includes an attacker with database access plus application config access. Deterministic encryption of searchable values leaks equality patterns by design; document and accept that tradeoff explicitly, or avoid searchable fields entirely.
• You require audited, formal cryptographic review — this is a community package, not a certified crypto module. For regulated workloads, treat it as an implementation convenience and validate against your own security review.

Release-specific note: 4.1.0 is a compatibility and maintenance release — Laravel 13 and PHP 8.5 support, plus a CI dependency bump. No breaking changes, no deprecations, no new features. Low upgrade risk from 4.0.0, but the practical takeaway is stability, not new capability: plan accordingly and do not expect upstream to close the gaps listed above.

How to Pitch It (Stakeholders)

For executives: We can meet our data-at-rest encryption obligations for sensitive customer fields without a dedicated platform project. This is an existing, actively maintained open-source component that plugs into our current Laravel codebase; the latest release confirms it stays compatible with the Laravel 13 and PHP 8.5 upgrades already on our roadmap, so it does not create a future migration liability. Estimated effort is a per-model change rather than new infrastructure. Two constraints to note: it supports exact-match search on encrypted fields but not free-text or range queries, and key management stays with us — if we later need per-tenant keys or an HSM-backed rotation policy, that becomes separate scoped work.

For engineering: Use the package's trait and cast to encrypt sensitive attributes at the model layer, keeping key handling on Laravel's existing config. It gives us consistent IV handling and a searchable-hash companion column for exact-match lookups, replacing the ad-hoc Crypt:: calls and hand-rolled searchable columns we tend to accumulate. Version 4.1.0 adds Laravel 13 and PHP 8.5 support with no breaking changes, so it is safe to adopt alongside the framework upgrade. Be explicit in code review about which columns are searchable — deterministic hashes leak equality, so anything that does not need lookup should be encrypted non-searchably. If a feature needs range queries, sorting, or LIKE on an encrypted field, raise it early: that is a design change, not a package configuration.