I was afraid to run queue jobs on a copy of production, so I built a Laravel package

Description and use

The laravel-db-safe-mode package enables safe debugging of queue jobs on a production database clone by redirecting emails and blocking external calls, preventing accidental contact with real customers.

Problem

Running queue jobs on a cloned production database risks sending real emails, SMS, Slack notifications, or making outbound API calls to real customers.

Outcome

The package enables safe debugging on production‑cloned data by redirecting emails, blocking notifications, and preventing unintended writes, while still allowing intentional writes via SafeMode::allowWrites.

Workflow

• Clone production database to local machine
• Install laravel-db-safe-mode as a dev dependency
• Set SAFE_MODE=debug and [email protected]
• Run queue workers (e.g., php artisan queue:work --once)
• Observe job execution and email redirection to own inbox
• Use X‑Safe‑Mode‑Original‑Recipients header to see intended recipients
• If needed, enable strict mode for live production DB connections

Evidence

I couldn't reproduce it locally with seeded data, so I did what a lot of us do: I cloned the production database to my machine, ran the queued jobs by hand, and sprinkled logs through the code to see where things went wrong.

Source

What if this actually sends a renewal email to a real customer?

Source

It has two modes. debug: the one I needed for that bug. Database writes and the queue workers you start yourself run normally, so you can actually reproduce the problem. But nothing reaches real people: every email, on every mailer, is redirected to your own inbox (or not sent at all and just logged)

Source

strict: for when you connect your local app straight to the live production database to look at something. Reads work, but every write throws a WriteBlockedException, queue workers and the scheduler refuse to start, and outbound mail, notifications and HTTP are blocked.

Source