SETUP GUIDE · N8N + SUPABASE
Give a Supabase update a way back.
Connect one disposable row, record one change, then verify one undo. This setup protects selected updates made through the connector after capture is configured.
1. Prepare a disposable table.
In the development project’s SQL editor, run the connector installer, then the demo table SQL. The installer creates connector functions and an empty registry; the demo script explicitly creates and registers rewind_demo_customers.
Start with this fixture. Registering an application table adds a revision column and trigger and has specific schema requirements. Review the full connector guide before changing a real table.
2. Prepare the two n8n workflows.
Sign in to Rewind and open Connect. Choose n8n and a Supabase row, enter the development project URL, then prepare and download the capture and recovery workflows. Import both into n8n using Import from File.
Keep the demo alias, row ID and patch for this first run. The capture example changes one row; it does not wrap arbitrary Supabase nodes or protect every workflow automatically.
3. Add credentials in n8n.
Create separate Rewind recording and worker keys in Connect. Use them as n8n Header Auth credentials with Authorization: Bearer …. Create the Supabase server-side credential with apikey: … in n8n’s credential store.
The Supabase server key bypasses row-level security. Keep it server-side: do not paste it into Rewind snapshots, workflow exports, browser code or public messages. The downloaded workflows contain no credentials.
4. Capture the test change.
Select the Supabase credential on Read row and Capture update, and the recording credential on Record operation. Run the capture example once. It changes the demo row from active / 5 seats to inactive / 3 seats and records the connector’s actual snapshots and revision.
If recording fails after a successful update, retry only Record operation with its saved payload and idempotency key. Do not rerun the whole workflow: that repeats the forward action. If the update response is lost, inspect the real row before retrying anything.
5. Approve, restore and verify.
In Rewind, open Workflows → All changes, select the test update, preview its undo and approve it. In the recovery workflow, select the worker credential on Claim approved job and Report outcome, and the Supabase credential on Read current resource and Conditional restore. Run the worker manually.
Check Rewind’s report and the actual Supabase row. A queued job is not a completed undo. Read the recovery checklist.
6. Prove a later edit is protected.
Capture another test update, edit that row in Supabase, then approve the undo and run the worker. Recovery should stop with a conflict and preserve the newer edit. See how the version check works.
Only enable a recovery schedule after both manual tests pass. Capture must be installed before changes happen; Rewind cannot reconstruct an update it never recorded.