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

说明与用途

laravel-db-safe-mode 包允许在生产数据库克隆上安全调试队列作业，通过重定向邮件和阻止外部调用，防止意外联系真实客户。

问题

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

结果

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.

工作流

• 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

证据

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.

来源

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

来源

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)

来源

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.

来源