The staging copy with the live Stripe key.

Part 6 of 6·Know before your clients do

You need to try a plugin update before the client sees it. So you copy the shop to staging. One export, one import, a search and replace on the address. Ten minutes later the copy looks exactly like the live site.

It is exactly like the live site. Every customer is in there with a name, an email, a phone number and a home address. Every order. The live Stripe key sits in the payment settings. The webhook to the CRM is still active. The renewal reminders are still queued for tonight.

Now count who can reach that copy. The contractor you gave a login to. A plugin on staging with a known flaw. The staging password that went round in a chat. None of them were ever meant to see a real customer. On a plain copy, all of them can.

Why a plain copy falls short

The usual staging tools are good at what they do. A staging plugin or the host's staging button copies the site and rewrites its URLs. They leave every customer, every order, every form entry and every live key where it was. Most leave cron, webhooks and the payment gateway running.

The other usual fixes each cover a slice. A search and replace changes URLs and nothing else. A general masking tool works column by column. It does not know that WordPress keeps billing addresses as rows in a meta table, that Action Scheduler keeps emails inside JSON. It does not know that a PHP serialized value breaks when its length changes or that a gateway set to testmode = no is live.

Then there is the step nobody takes. After the copy, nobody reads it back to see what is really in there.

Echo, from earlier in this series, seals what a staging site sends. Roadie works one step before that. It makes the copy itself safe, so there is nobody real in it to send to, then checks the result.

Make the copy safe, then prove what is in it

Roadie (opens in a new tab) copies production to staging and only ever reads production. On the way, every real person gets one fake that stays the same in every table, inside serialized and JSON values too. The fakes use reserved email domains and fictional phone ranges, so they can never reach anyone. Passwords are made unusable and sessions removed.

Live keys for Stripe, PayPal, WooPayments, Mollie, SendGrid, Twilio and more become the test keys you set. Without one they are blanked. Side effects go off: WP-Cron, Action Scheduler, WooCommerce webhooks, gateways in test mode and mail handed to Echo's seal. It knows WordPress, WooCommerce and the common form and shop plugins, Laravel and any SQL schema you describe.

Then it reads the finished copy, never what it believed it changed. After a copy it checks that no production value it replaced survives anywhere. That is the part I care about most. A tool telling me it pseudonymised everything is a claim. A check that reads the copy afterwards is evidence.

Here it is on its own demo shop: a made-up WooCommerce store with forty fake customers, a live-looking Stripe key and an active webhook. The first tab is a plain file copy of that shop, checked by Roadie. The second is the same shop copied by Roadie.

That is a real run on my machine, with dump files only. On the plain copy Roadie found the live Stripe keys, the gateway in live mode, the active webhook and hundreds of real-looking emails and phone numbers. It fails. On its own copy the same checks found nothing. The grey dots are checks a dump file cannot answer, such as whether the site says it is staging. Point Roadie at a site folder and those run too.

Every run writes a signed report. rhythm roadie report check tells anyone whether it changed since. The signature says who ran Roadie, which version and rules, on which input. It does not say the copy holds no personal data. Roadie never claims that.

Already have a staging copy someone else made? rhythm roadie prepare makes it safe in place, after a backup. rhythm roadie verify checks any copy, even a dump a client sends you.

What it will not do

• It never writes to production. A target that is production, is the source or says it is production is refused before anything is written.
• It pseudonymises. It does not anonymise. Order totals, dates, products and names written in free text stay, so treat the copy as personal data.
• It does not copy files or uploads, clear Redis or rebuild search indexes. The plan prints a copy command for the files that leaves out the usual folders with personal data in them.
• Its kill switch works inside the site. A server crontab or a queue worker that was already running sits outside it. The keys are blanked so those calls fail at the provider. Blocking outbound traffic at the host is the only certainty.
• Never push a staging database back to production. Its customers are fake.

Roadie is free and open source under the MIT licence. The code is on GitHub (opens in a new tab) and the whole set is on the open source page.