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.

Источник