// docs / backups & snapshots

Backups & snapshots

Openflow has two separate concepts for saving an instance's state: snapshots and backups. They're kept separate because they solve different problems.

Two concepts

	snapshot	backup
contains	`flows.json` + encrypted credentials	tar.gz of the whole `/data` directory
typical size	kilobytes	megabytes to gigabytes
purpose	promote a flow between instances or projects	disaster recovery
cadence	on demand, from the editor toolbar or dashboard	nightly cron, configurable per instance
restore is	fast (seconds), stops + rewrites flows, restarts	slower, stops + untars the archive over `/data`, restarts
UI location	"Take snapshot" in the editor toolbar; Backups tab dropdown	Backups tab in the dashboard

Snapshots

A snapshot is a serialized view of the flow itself. The intent is to be the unit you promote across environments: take a snapshot in dev, restore it into staging, observe, restore it into prod. The data is small enough to keep in Postgres rather than as files on disk.

Snapshots are stored on the snapshots table with the flow JSON, the encrypted credentials, the credential-decrypt secret needed to read them back, and the node count. They're not tied to a particular instance after capture; you can apply them to any instance.

From the editor toolbar

The toolbar at the top of the Node-RED editor has a Snapshot button and a dropdown caret. Click the button to capture the active flow. Click the caret to see the last 10 snapshots; click any one to roll back to it. Restoring stops the instance, rewrites the flow files, and starts it again, so the editor disconnects for a few seconds.

From the dashboard

The instance's Backups tab also lists snapshots. From there you can capture from outside the editor, and you can apply a snapshot from one instance to another (for promotion across instances or projects).

Backups

A backup is a tar.gz of the instance's entire /data directory: flows, credentials, any node-state, palette installs, Node-RED's own config files. They're written to BACKUP_PATH/<instanceId>/<timestamp>.tar.gz on the host, with a backups row in Postgres holding the metadata (filename, checksum, size, status).

Schedule

Per-instance, configured in instance settings. Defaults: enabled, nightly at 02:00, 7-day retention. Backups run from the manager's cron and don't pause the container.

On demand

The Backups tab has a Back up now button. Clicking it spawns the backup job in the background and surfaces a toast; the row appears in the list immediately with status in_progress and flips to completed or failed when the tar finishes. The dashboard auto-polls while there's a job in flight.

Restoring

From a snapshot

Open the editor and click the caret next to Snapshot, OR open the instance's Backups tab.
Find the snapshot. Click Restore.
The manager stops the instance, rewrites flows.json and flows_cred.json in /data, updates credentialSecret on the row, and starts the instance.
Refresh the editor after a few seconds.

From a backup

Open the instance's Backups tab.
Find the backup. Click Restore and confirm.
The manager stops the container, extracts the tar over the existing /data, and starts the container again.

Retention & storage

Backups older than the per-instance retention window (default 7 days) are deleted on a daily cron. The file is unlinked and the row is removed.
Snapshots have no automatic retention; they live until you delete them. The dropdown and the Backups tab both surface explicit delete actions.
BACKUP_PATH is just a directory on the host. If you want it backed up off-box, your existing backup system (restic, rsnapshot, borg, whatever) can treat BACKUP_PATH as input. The contents are immutable tar.gz files.