Protect your Seedly Sites instance - Postgres and media backups, disaster recovery, and portable per-client content export.
Loading the guide...
Did this answer your question?
Help us make the guides more useful.
0 helpful · 0 not helpful
Protect your Seedly Sites instance - Postgres and media backups, disaster recovery, and portable per-client content export.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Your platform's state lives in three places. A real backup plan covers all three.
The platform backs up your Postgres content itself. A super admin can create, download and restore a backup by hand from Backups in the operator dashboard (/operator/backups), and an automatic backup runs on a schedule and keeps a rolling set of recent ones. Your CMS runs the automatic backup itself. Your GitHub repo also runs it until you run npx pnpm run setup:scheduler, and while both run it, your kept backups reach back half as far.
The Railway snapshots and manual dumps below are extra layers on top of this. Do them too.
pg_dump inside Railway and let it stream back to your computer with railway ssh -s Postgres -- pg_dump > backup.sql (this needs the Railway CLI installed and linked). Do this whenever you are about to do something you are not sure about.R2 is durable, but a bad delete is still a bad delete. Periodically sync the bucket to another location (a second bucket, or S3) with any S3-compatible tool using your R2 credentials. At minimum, do this before any bulk media operation.
Store every environment variable value in a password manager or encrypted vault: the platform's generated secrets, your provider keys, and your local env file. Losing the session-signing secret in particular signs everyone out and invalidates signed tokens.
Backups protect the whole platform. When you need just one client's content, to hand a leaving client their site or to move a site between instances, each site has its own Export / Import tab.
Export All Content downloads that site's pages, blog posts, categories, locations, redirects, and settings as a single JSON file. Media is referenced by URL, not bundled. Import reads an export back in and skips any record whose slug already exists, so a re-import is safe.
The Offboard client action goes further: it builds a self-contained, host-anywhere copy of the client's live site, every image downloaded into the bundle and nothing calling back to the platform, alongside the content export. Use it when a client is leaving; it only generates the bundle and never revokes access or removes hosting.
The golden rule: never restore a full backup over a live production database without first taking a current dump of that live database. A restore is destructive; give yourself a way back.
A client may leave with their site, or you may want a portable copy of one site's content. Portability is a feature of the platform, not an afterthought.
The Export / Import screen explains what a departing client actually receives and how they can use it with any host or developer, so you can show them rather than describe it.
The bundle is checked before you get it. If any image in the export still points back at this platform, or is referenced but missing from the bundle, the build fails and tells you, rather than handing over an archive that looks complete and renders with broken images on the client's new host. A takeout that succeeds is self-contained.
If a client is taking their domain with them:
/admin (Tenants, open the client) and remove it from Cloudflare.Do not delete the tenant or its hosting project until the client confirms they are fully moved. Deleting hosted environments is a one-way action.
If a client asks you to delete their data (not just export it): export first, then remove the tenant and its media, and record that you did so. Keep whatever you are legally required to keep (billing records, for example) separately.