carlos / platform Public

Every instance's database already streams to object storage through Litestream, and restore drills run (carlos ops restore-verify, hibernate-verify). What an app owner can't do is use any of it. There's no member verb to snapshot before a deploy, or to restore an instance's database as it was at a moment into somewhere they can open.

Asking for, roughly:

carlos restore --app ips --host kpmg.bdn.oncarlos.com --at 2026-09-12T09:00Z --to canary/kpmg-tuesday

That would start a canary whose database is the replica at that time, on its own host and channel, touching nothing live.

For a statutory record-keeping app this is the feature, not a nicety:

• "what did the file say on Tuesday" becomes a URL;
• a migration can be rehearsed against a tenant's real data before it reaches them;
• a bad write has an undo that isn't a restore over live data.

Related: #15 (resetting a canary, and the seed-over-live-data hazard) and #117 (fenced offline maintenance). Restoring into a canary rather than over the instance sidesteps the hazard #15 describes.

--- Filed from the ips repository (Turnkey's insolvency practice system, built on rastrillo v0.26.0 and deployed on CARLOS), where this was worked around. Paths without a repository prefix are in ips.