How to export and back up your Seedly CRM instance, get your data out on your own terms, and run a restore drill you can trust.
Loading the guide...
Did this answer your question?
Help us make the guides more useful.
0 helpful · 0 not helpful
How to export and back up your Seedly CRM instance, get your data out on your own terms, and run a restore drill you can trust.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
You own Seedly CRM outright: the source you deploy and the data inside it are yours. Ownership is only real if you can get your data out and put it back. This page covers what holds your state, how to export and back it up, and how to prove a restore works before you need it.
Seedly CRM runs as source you own, deployed on infrastructure you control. By default the backend runs on Convex Cloud and the frontend is hosted on Vercel. Your state lives in two places, and a real backup plan covers both.
The frontend itself holds no state. It is rebuilt from the source you own, so there is nothing to back up there beyond its environment variables.
Because the default backend is a managed service, routine backups are handled for you. Convex Cloud keeps its own snapshots so a recent version of your data is recoverable within a recovery window without any action on your part. That is the safety net, not the whole plan.
Take your own export before anything risky. Before a version update or a large data operation, take a snapshot you keep off-platform. The Convex CLI produces a portable export of your data and file storage:
Keep that file somewhere outside your deployment (an encrypted drive, a private bucket, a password-managed vault). Do this whenever you are about to do something you are not fully sure about. A snapshot you own, sitting off-platform, is the difference between a bad afternoon and a lost business.
In-app exports for specific data. Alongside the full snapshot, many modules can export their own records to CSV from inside the app (contacts, the audit log, reports, and more). These are useful for handing a client their records or pulling a slice into another tool, but they are not a substitute for a full snapshot.
Store every environment variable value in a password manager or encrypted vault: the secrets the setup process generated for you, your provider keys, and your local env file. The session-signing secret matters most. If you lose it, everyone is signed out and previously signed tokens stop being valid, and no data backup restores it. The setup guide that ships with the product lists what exists and what each value is for.
This is the ownership story, and it is a feature, not an afterthought. Two paths get your data out on your own terms:
If you ever choose to move the backend off Convex Cloud, you can: because you received the source for both halves of the stack, an advanced operator can run the backend elsewhere. See the Architecture page for how that fits together. Either way, the data is portable and the choice is yours.
The golden rule: never import a full backup over a live production deployment without first taking a fresh export of that live deployment. An import is destructive. Give yourself a way back before you take one.
A backup you have never restored is a hope, not a backup.
Do one real restore in your first month, into a scratch or development deployment, so you know the steps cold before you ever need them under pressure:
Point that at a non-production deployment, confirm your records and a few media files come back intact, and you will trust your backups for real. A restore you have rehearsed is worth ten you assume will work.