Add Patching/Maintenance/Upgrade documentation + backup and restore

[captainfalcon23]

If we deploy this to Cloudflare, my understanding is this repo get's copied to the users' repo, and the infra deployed to cloudflare from there. It would be great if there was some upgrade path from the UI, or docs on how to check for updates and keep our repo in sync with the public repo to ensure we are always running the latest and greatest.

It would be great to see backup and restore included by default too, perhaps via a schedule where the backend D1 and R2 can be backed up externally, and the ability to restore from a backup.

[joeblew999]

I’m also concerned about this area .

for a beta product I don’t expect api stability.

I think there is an export feature , and maybe that can then be used to pull everything out and then import to a new instance ?

[ascorbic]

Most of EmDash is in the emdash Astro integration, which can be upgraded like any npm package. The database backends use migrations, so if anything needs upgrading that should be handled.

[captainfalcon23]

So does that mean, we need to watch for changes in the source, merge those changes into our repo, and let the cf integration rebuild and deploy it?

Forgive me for my lack of knowledge here, I have rarely used cf to deploy apps, but I’d love to use it for this one considering it was all designed for native cf technologies.

I didn’t see any backup utility in the ui also, does it mean as long as the db and bucket are there, we would be able to tear the app down and rebuild it? And we need to backup those components separately?

[swissky]

Picking this up — the backup half of this thread never got an answer, and the building blocks have existed in core for a while now. Current state and a concrete plan:

What already exists today:

• D1 Time Travel covers point-in-time recovery out of the box: every EmDash site on Cloudflare can restore its database to any minute in the last 30 days (7 on the free plan), always on, zero config, via wrangler d1 time-travel restore. Most people in this thread probably already have better disaster recovery than they think — it's just not surfaced anywhere in the docs.
• Core has a portable snapshot generator (api/handlers/snapshot.ts, built for the DO preview database) whose header literally says "Future: CLI export, backup, site migration". It already handles dynamic content-table discovery, schema capture, and excluding auth/secret tables.
• The scheduled-maintenance hook (runScheduledTasks: publishing sweep + system cleanup) is the natural place for a periodic backup, and the storage abstraction (R2/S3/local) can hold the archives — no Cloudflare API token needed, since the app exports its own data.

What I'm proposing to add (PR incoming, linking back here):

1. A Backup section in admin settings: one-click download of a full content backup (all content incl. drafts, schema, taxonomies, menus, media metadata, site settings — no user credentials/sessions/secrets), plus a toggle for daily automatic backups stored in the site's own bucket under backups/, with a retention setting. An info box points Cloudflare users at Time Travel for point-in-time restore.
2. A docs page covering the full story: Time Travel (you already have it), manual export, scheduled archives, wrangler d1 export for offsite dumps, and the SQLite-file path for Node deploys.

Deliberately out of scope for the first cut: an in-admin restore button. Restore is destructive and deserves its own careful design (CLI first, probably). Media binaries are also not bundled into archives — metadata is included, and the files live in the same bucket the archive does.