Building Twinstack came out of one of mine three days of scripts, half a dozen half-broken pg_dumps, and one very confused staging environment. Since launching, the most-repeated story I hear is auth: someone runs a "clone" that copies the users table but not the password hashes, and their entire user base is silently locked out until Monday morning.
So what's yours?
Staging refresh that turned into a full-day quest?
The one storage bucket you forgot until a customer complained?
Regional migration where the RLS policies just didn't come along?
Or a happy path story I can learn from?
Curious to hear where the current tooling breaks down for you. I'm collecting these; they're what shape the roadmap.
How does it handle live databases during the clone process, especially if there are active writes happening on the source project at the same time?
@yaseminneh8uon Good question, and the honest answer has two halves.
On the database side — Twinstack shells out to pg_dump, which starts a serializable read-only transaction and dumps against that snapshot. So schema, data, and the whole auth schema (users, sessions, identities) all reflect one consistent point in time: the moment the dump began. Writes happening during the dump don't corrupt anything — they're just outside the snapshot and not included. Same guarantee Postgres gives its own logical backups.
On the storage side — files live outside Postgres, so there's no shared transaction. Twinstack lists the source's buckets, then streams each object. If a new file lands during transfer, it'll show up on your next sync but not this one. If a file is deleted mid-transfer, we log it as a skip. The metadata rows referencing that file did make it through in the dump, so the target might briefly reference an object that isn't there yet — which is why we recommend syncing during low-write windows for the tightest consistency, or running a second pass after (Twinstack's per-object state makes the second pass fast; it only touches what changed).
Roadmap includes an "advisory lock" mode that pauses writes for the ~2s the pg_dump snapshot needs to start, for teams that want stronger guarantees.