Add the ShouldBeEncrypted interface to a Laravel job when its payload contains personal data, tokens or anything you would not want readable in Redis or a database table. Laravel then encrypts the job before it is pushed to the queue. It protects data at rest in the queue, not data inside your code.
What is in a queued job
A queued job is a serialized object sitting in a store until a worker picks it up. That store might be Redis, a jobs table, SQS or Beanstalkd. Anyone with read access to it, a backup of it, or a debugging dashboard that shows payloads can read what the job carries.
The Laravel documentation also describes how models are handled. If you pass an Eloquent model into a job constructor, only its identifier is serialized, and the model is fetched again when the job runs. That keeps payloads small and keeps most record data out of the queue. Plain arrays, strings and DTO properties are different: they are stored as given.
How to turn it on
use Illuminate\Contracts\Queue\ShouldBeEncrypted;
use Illuminate\Contracts\Queue\ShouldQueue;
class SendStatementEmail implements ShouldQueue, ShouldBeEncrypted
{
// ...
}
The documentation says Laravel will automatically encrypt the job before pushing it onto the queue. It uses the same encrypter as the rest of the framework, so it depends on your APP_KEY.
When it makes sense
| Payload content | Encrypt the job? | Better first step |
|---|---|---|
| Model id only | Usually not needed | Keep passing ids |
| Email address or name | Consider it | Pass the id and load the record in the job |
| API token or password reset secret | Yes, or avoid putting it in the job | Look it up at run time |
| Large file contents | Avoid | Store the file, pass a path |
The cleanest control is to keep sensitive values out of the payload. Pass an id, and read the sensitive column when the job runs. Encryption is the backstop for the cases where that is not practical.
What it does not do
It does not hide data from anyone who can run code in your application, since workers decrypt the payload to run it. It does not protect job names and queue names. It also ties job readability to your key, so a key rotation matters. Laravel supports APP_PREVIOUS_KEYS so that older values can still be decrypted, but jobs sitting in a long retry window deserve a check after any rotation.
A short review routine
- List jobs that carry request data, user data or credentials in their properties.
- For each, ask whether an id would be enough.
- Add
ShouldBeEncryptedto the remainder. - Check where failed jobs are stored, since the failed job record keeps a copy of the payload.
- Restrict who can open any queue dashboard in production.
Quick check
Does ShouldBeEncrypted slow jobs down?
It adds an encrypt and decrypt step per job. For most workloads that is small next to the job itself, but measure it if you process very high volumes.
Are failed jobs encrypted too?
The docs describe encryption before the job is pushed to the queue. Check what your failed jobs table actually stores in a test environment before assuming.
Safeguard's asset discovery and policy gates can help you keep an inventory of the services and queues your applications depend on. Run a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
