Import, export and backups

Your data is yours and it leaves in a readable shape. There are four mechanisms: a manual export, an import, a check that proves an export restores, and scheduled backups to a git repository or a storage bucket you own. The Your data section of the Data page shows the state of all of them, and everything that can leave the server.

Export

The Data page has two downloads:

• Download export — a zip of the workspace you are in, containing simplist.json (what an import reads), a files/ directory of the actual file bytes, a csv/ directory with one spreadsheet per model, and a README.md explaining the lot.
• Download all workspaces — one zip covering every workspace you belong to, with a top-level manifest.json and a folder per workspace.

Both are plain JSON, CSV and files, documented field by field in The export format. Nothing is locked in a proprietary container: the CSVs open in any spreadsheet app, with each relation shown as the linked records’ names beside their ids, and each file column giving the file’s path inside the zip.

Checking an export

Data → Check an export takes a zip and tells you whether it would restore, without restoring it: Simplist runs the real import and then undoes it, so nothing in your workspace changes. A good export reports what it holds (models, fields, records, links and files); a damaged one reports why the import would stop. Do this occasionally with a recent export, so the day you need a backup is not the day you learn it was broken.

Import

Importing a workspace zip on the Data page restores its models, fields, documents, relations and files.

What happens depends on the zip:

• A single-workspace zip imports into the workspace you are currently in.
• An all-workspaces zip recreates each workspace fresh, named "<name> (imported)", with new ids — so importing never overwrites a workspace you are already using.

Imports count against your plan’s limits like anything else you create.

Scheduled backups to GitHub

If your Simplist instance has the GitHub integration configured, the Backups page can commit your workspaces to a repository you control on a recurring schedule — hourly, daily or weekly.

Connecting GitHub is a one-time, account-level action. After that, each workspace picks its own destinations independently, and a workspace can have more than one — a private archive and a public mirror, say.

Each run is a single commit writing one JSON file per item:

<chosen-dir>/
  user.json
  models/{model_id}.json                 # model + its fields
  documents/{model_id}/{doc_id}.json     # values, relations, file references
  files/{file_id}-{filename}             # the file bytes

One file per item is deliberate: a corrupted byte costs you that one item, not the archive. And because the destination is a git repository, the repo’s own history is your backup history.

A few things that follow from the design:

• Things you delete in Simplist are removed in the next commit, scoped to those four directories — so a README, a .gitignore or screenshots you added at the repo root are left alone.
• Every destination is unique. A given repository, branch and path can be claimed by exactly one destination; a second one is refused. Two workspaces backing up to the same repo just use different directories.
• Every run is recorded — success, partial, rate-limited, failed, or skipped because nothing changed. The Backups page shows them as a scrollable log and as a contributions-style calendar, one cell per day.
• Repeated failures email you, on each of the first three in a row, rather than failing quietly.

If the repository you want is missing from the dropdown, use Manage repository access on GitHub to grant access to it, then reload.

Note that the backup layout and the export zip are not the same shape: the zip is one monolithic file, the backup is a directory tree.

Scheduled backups to a bucket you own

The Backups page can also write each workspace to an S3-compatible storage bucket of your own: AWS S3, Cloudflare R2, Backblaze B2, Wasabi and similar. Choose Add bucket destination, then give:

• the endpoint (leave it empty for AWS itself; otherwise your provider’s https S3 endpoint),
• the region, the bucket, and optionally a folder inside it,
• an access key and secret. Use a key that can only write to that bucket. The secret is stored encrypted and never shown again; to change it, enter a new one.

The bucket gets the same layout as a GitHub backup. Each run writes what changed and removes what you deleted, touching only user.json, models/, documents/ and files/ under your folder, so anything else you keep in the bucket is left alone. Runs are logged on the Backups page, and repeated failures email you, as for GitHub.

Deleting your account

Account deletion is available from your account settings and removes your data. Export first if you want a copy.