Backups & Data Export

Your platform's state lives in three places. A real backup plan covers all three.

---

What Holds Your State#

1. Postgres (on Railway) - all your content: sites, pages, blog posts, media records, settings, users. This is the big one.
2. R2 (on Cloudflare) - the actual media files clients uploaded.
3. Your secrets - the environment variables on Railway and GitHub, and your local env file. These are not in the database; if you lose them, you cannot authenticate even with a perfect data backup.

---

Postgres Backups#

• Railway snapshots. Railway's Postgres offers scheduled backups; enable them in the Postgres service settings and know your retention window.
• Manual dump before risky changes. Before a version update or a large data operation, take your own dump with a standard pg_dump against the database's public connection URL, and keep the file off-platform. Do this whenever you are about to do something you are not sure about.
• Restore drill. A backup you have never restored is a hope, not a backup. Do one restore into a scratch database in your first month so you know the steps cold.

Media (R2) Backups#

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.

Secrets Backup#

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. The env-vars reference lists what exists.

---

If You Delete Something by Mistake#

• A single record (a page, a post): restore just that record's data from a recent backup rather than rolling everything back. If it was only unpublished, not deleted, just re-publish; remember deploys are separate from data.
• A whole site's content: restore your most recent snapshot into a scratch database, extract that tenant's rows, and bring them back. Do not restore a whole snapshot over the live database while other clients are active unless you accept losing everyone else's changes since that snapshot.

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.

---

Data Export (Client Takeout)#

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.

Two Kinds of Export#

1. The published static site. Every site publishes as clean, self-contained static files (HTML, CSS, images). Those files ARE the site, with no runtime framework to carry along; a client can host that output anywhere.
2. The content bundle. The portal includes a per-site takeout/offboarding export that packages the site's pages, posts, media, and settings for handoff, so the content itself (not just the rendered output) can move. Open the site and use its Export / Import surface.

Handing Over a Live Site#

If a client is taking their domain with them:

1. Give them the published static output.
2. They point their domain's DNS at wherever they will host next.
3. Once they confirm the cutover, remove the domain from the tenant in your portal and 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.

Privacy Requests#

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.