localStorage by default), preventing data loss when the browser closes unexpectedly.
How It Works
- When
autoSaveDraftis enabled (default:true), FlowDrop saves the current workflow to draft storage periodically - The save interval defaults to 30 seconds (
autoSaveDraftInterval: 30000) - Drafts are keyed by workflow ID and scoped per instance, so multiple editors on one page never collide
- When a workflow is loaded, FlowDrop checks for a matching draft and offers to restore it
- After a successful save to the backend, the draft is cleared
Draft storage key format
Draft storage key format
The default instance keys drafts as
flowdrop:draft:<workflowId> (and
flowdrop:draft:new for an unsaved workflow). Editors mounted with an
instanceId get scoped keys: flowdrop:draft:<instanceId>:<workflowId>.Configuration
Security Considerations
Drafts contain the complete workflow JSON, including node configuration values. If your users enter API keys, tokens, or other secrets into node configs, those values end up in browser storage in plain text. Keep in mind:- On the default
'local'backend, drafts remain stored on the device even after the tab or browser is closed, until they are saved or cleared - Neither
localStoragenorsessionStorageprotects against same-origin script access (XSS) — both are readable by any script running on your page - On shared browser profiles, leftover drafts are readable by the next user via DevTools
- Call
clearAllDrafts()on logout - Use
draftStorage: 'session'so drafts are removed when the tab closes - Supply a custom
DraftStorageAdapter(e.g. an in-memory store) - Disable drafts entirely with
features: { autoSaveDraft: false }
Choosing a Storage Backend
ThedraftStorage mount option controls where drafts live:
| Value | Backend | Survives reload | Survives tab close | Notes |
|---|---|---|---|---|
'local' (default) | localStorage | ✅ | ✅ | Best crash recovery; clear on logout for shared devices |
'session' | sessionStorage | ✅ | ❌ | Per-tab; drafts do not survive crash-and-reopen |
| custom adapter | up to you | — | — | Implement DraftStorageAdapter |
clearAllDrafts() helper uses the most recent mount’s backend unless you pass it an adapter explicitly.)
A custom adapter implements four synchronous methods. Async backends — IndexedDB, network storage, WebCrypto encryption — cannot implement the interface directly; put a synchronous in-memory cache in front and flush to the async backend separately. Beware that an async method will type-check here (a Promise is assignable to void), but its errors are silently swallowed.
Disabling Auto-Save
Faster Auto-Save
For critical workflows, save more frequently:Manual Draft Management with Events
Use theonBeforeUnmount event to save a final draft when the editor is destroyed:
Clearing Drafts on Logout
On the default'local' backend, drafts persist until they are explicitly cleared. FlowDrop has no notion of authentication, so it cannot clear drafts when the user signs out of your application — you must do this from the host application’s logout handler. On a shared browser profile, leftover drafts could otherwise be readable by the next user via DevTools.
The mounted FlowDrop instance exposes clearAllDrafts() for this purpose. It removes every key beginning with flowdrop:draft: — including instance-scoped sub-namespaces like flowdrop:draft:<instanceId>:<workflowId> — plus the custom draftStorageKey you configured at mount time (if any), and returns the number of entries removed.
Storage Limits
Browsers typically limitlocalStorage to 5-10MB. Large workflows with many nodes and complex configurations could approach this limit.
If storage is full:
- The draft save fails silently
- The editor continues working normally
- No data is lost from the active session
Combining with Backend Save
A typical save flow:Next Steps
- Event System — all lifecycle events including save
- Framework Integration — mount options including features
- Troubleshooting — draft recovery issues