Why you can always get back to a working store

When something goes wrong (a security concern, a bad change made outside Reqursor Platform, a failure in the systems behind a store), the question that matters most is how fast and how confidently a store can get back to a version that worked. Reqursor Platform's answer comes from the same approach that makes everyday changes safe: recovery isn't a special procedure with its own risks. It's the same re-deploy (putting a version live again) used for routine changes.

The record survives what the running store doesn't

A store's recorded setup and the live store are two different things. Even if something goes badly wrong with the live store, the recorded setup is unaffected: the last version that worked is always intact and available. See Core concepts for how the intended setup and the real, current setup relate.

Recovery is a re-deploy, not a rebuild

Once whatever caused the problem is understood and contained, restoring the store is the exact same operation as any other change: point the engine at a version that worked and let plan, apply and check do the rest. This is deliberate. There is no separate "disaster recovery mode" with its own, less-practiced way of working: recovery runs through the identical process that every ordinary change already runs through, thousands of times over.

Replacing a secret works the same way

When a secret (a password or key your store uses) needs to be replaced (routinely, or in response to a specific concern), Reqursor Platform treats it as a re-deploy, not a one-off manual process:

1. The new secret value is put in place.
2. A deployment is started for every store that uses it.
3. Each store picks up the new value automatically as part of that deployment.

The previous value stays available briefly during the switch, so the replacement can be safely reversed if something doesn't check out: the same safety margin any deployment gets.

Why this matters for your agency

• Recovery is boring, on purpose. It's used on every ordinary change, not held in reserve for a rare emergency, so it's never untested when you actually need it.
• Nothing is store-by-store manual work. Replacing a password or restoring a version that worked doesn't mean touching every affected store by hand.
• The recorded setup is always the answer to "what should this look like?" Recovery never has to guess: it applies the same recorded setup that the check that a store is set up as intended already compares against.

Where to go next