Weave Code
Laravel Encryptable Laravel Package
maize-tech/laravel-encryptable
Laravel Encryptable adds transparent encryption for Eloquent model attributes, keeping sensitive data secure at rest while preserving a familiar query workflow. A simple trait and cast setup lets you encrypt, decrypt, and search encrypted values without restructuring your models or database.
Easily anonymize sensitive data through eloquent queries
Frequently asked questions about Laravel Encryptable
- How do I install maize-tech/laravel-encryptable in a Laravel app?
- Install it with Composer using composer require maize-tech/laravel-encryptable. There is no service provider ceremony beyond optionally publishing the config file, so the change surface is the Composer install plus config publishing if you want to customise behaviour. After that you add the trait and cast to the models that hold sensitive columns.
- How do I encrypt an Eloquent attribute with this package?
- Add the package trait to your Eloquent model and declare the sensitive attributes with its encryption cast. Encryption and decryption then happen transparently at the ORM boundary, so you read and write plaintext in PHP while ciphertext is what is stored in the database. No model restructuring or external services are required.
- Does it support Laravel 13 and PHP 8.5?
- Yes. Release 4.1.0 is a compatibility-only release that adds Laravel 13 and PHP 8.5 to the support matrix alongside a CI maintenance bump. It introduces no new API surface, no deprecations, and no migration steps, so an integration assessment from a prior baseline remains valid. Teams pinned to Laravel 12 should confirm their constraints actually resolve to 4.1.0 before adopting the new tag.
- Can I query encrypted attributes, for example with a where clause?
- The main value-add over Laravel's built-in encrypted cast is queryability ergonomics: the package supports whereEncrypted-style lookups so you can filter on encrypted attributes without restructuring your models. Because values are stored as ciphertext, plan for matching-style lookups rather than arbitrary SQL expressions on those columns. Complex reporting queries should be designed around the encrypted fields before you commit to them.
- Can I still use ORDER BY, LIKE, or range queries on encrypted columns?
- No. Ciphertext defeats LIKE, range comparisons, and sorting, so encrypted columns cannot be used in ORDER BY, BETWEEN, or wildcard searches at the database level. If you need those operations, keep a separate non-sensitive derived column such as a hash or bucketed value, or move the ordering logic out of SQL. Decide this before choosing which attributes to encrypt.
- What column type and length should encrypted attributes use?
- Ciphertext is materially longer than plaintext, so a VARCHAR(255) column can silently truncate encrypted values. Use a ciphertext-capable column type, typically TEXT or VARCHAR(512) or larger, sized against your longest expected payload. Even for existing plaintext columns this column change is part of adoption, not an afterthought.
- What happens if APP_KEY is lost or rotated?
- Encrypted columns are effectively unrecoverable if APP_KEY is lost or rotated without a re-encryption plan, so document key recovery and rotation procedures before adopting the package. The package keys off Laravel's app key and encrypter and deliberately does not handle key management or rotation orchestration. Test your rotation runbook against a copy of production data first.
- How do I migrate existing plaintext columns to encrypted ones?
- Treat it as a data migration rather than a code change: add ciphertext-capable columns, backfill through chunked queued jobs, dual-read during the transition, then drop the plaintext columns. Encrypted values cannot be backfilled with a single UPDATE statement, so plan for backfill throughput. Greenfield models need only the trait import plus correct column definitions.
- Is upgrading from 4.0.0 to 4.1.0 safe, and are there breaking changes?
- 4.1.0 is an additive minor release with no breaking changes, no removed methods, and no deprecations, and it requires no migration of its own. Upgrading from 4.0.0 is a composer update followed by a regression pass. Verify that your Laravel and PHP version pins actually resolve to 4.1.0 before adopting it.
- How does this compare to Laravel's built-in encrypted cast, and what are the risks?
- Laravel's built-in encrypted cast already covers encryption at rest, so this package's differentiators are per-attribute trait configuration and query ergonomics for encrypted lookups. If you need key management, rotation orchestration, or searchable encryption, look elsewhere or build that layer yourself, since the package intentionally does not address it. It is also a small-maintainer dependency, so apply your usual small-vendor policy and keep a fallback plan if maintenance goes dormant.
Weaver
How can I help you explore Laravel packages today?