Skip to content

Help Center

Backups and Data Ownership

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.

Last updated

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.

What Holds Your State#

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.

  1. Your Convex deployment. This is the big one. It holds your database (contacts, conversations, pipelines, invoices, workflows, audit history, and everything else) and the media files your team and clients uploaded, since file storage is built into the backend. One deployment, everything in it.
  2. Your secrets and environment. The environment variables set on Convex, the ones set on your frontend host, and your local env file. These are not part of an exported data snapshot. If you lose them you cannot authenticate or reach your providers even with a perfect copy of your data.

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.

Convex Backups and Exports#

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:

npx convex export --path seedly-backup.zip --include-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.

Secrets Backup#

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.

Getting Your Data Out#

This is the ownership story, and it is a feature, not an afterthought. Two paths get your data out on your own terms:

  1. The full snapshot. The export above is a portable copy of your entire dataset plus its files. It is yours to keep, move, or hand off. Nothing is locked to the platform.
  2. Per-record and per-module exports. The CSV exports inside the app let you take specific records with you, for example when a client leaves and wants their contact list.

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.

If You Delete Something by Mistake#

  • A single record. Deleted contacts move to the Trash and stay recoverable for a window before they are permanently removed. If it is still there, restore it in one click. See Data Retention for exactly what is recoverable and for how long.
  • More than the recovery window allows. Restore your most recent snapshot into a separate scratch deployment, pull out the records you need, and bring them back into production. Do not import a whole snapshot over your live deployment to recover a handful of rows.

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.

Restore Drill#

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:

npx convex import --path seedly-backup.zip

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.

Was this page helpful?