Backups & Schema Migrations

Mesh persists its entire configuration in a single JSON file and automatically protects it from schema changes.

Where is the configuration?

In the container: /data/config.json — mapped to the host via the volume mount.

Standard on Unraid: /mnt/user/appdata/itsweber-mesh/config.json.

Schema migration chain

Mesh has a migration chain (apps/web/src/server/config/migrations.ts). On container start runMigrations runs:

1. Reads the current config version from the JSON
2. If version < CURRENT_VERSION: runs the migration for every step
3. On success: persisted config has the new version
4. On failure: container does not start — logs show exactly which step failed

Current version: v17 (as of 2026-04-29).

Automatic backup before every bump

Before every schema bump the store creates a backup:

/data/config.json.pre-vN

Examples from a live system:

config.json
config.json.pre-v15
config.json.pre-v16
config.json.pre-v17

Existing backups are never overwritten — if pre-v17 already exists (e.g. because the container already migrated from 16→17 before), a new bump will not replace the backup.

Manual backups

Recommended: daily rsync to another host:

rsync -av --delete /mnt/user/appdata/itsweber-mesh/ backup-host:/path/to/mesh-backup/

Or snapshot the complete appdata path every few days — that is the Unraid standard via the Appdata Backup Plugin.

Restore

docker stop itsweber-mesh


cp config.json.pre-v17 config.json


docker start itsweber-mesh

On start the migration runs again — if the version was the same, it is a no-op.

What to do with a corrupted backup?

Mesh can start with an empty /data — the First Run Wizard runs through and creates a fresh config. So no data loss is possible, only configuration loss.

If the config.json is too badly corrupted:

mv config.json config.json.broken

docker restart itsweber-mesh

Schema version history

Full list: apps/web/src/server/config/migrations.ts.

Pre-release validation

For major schema bumps we test:

1. Copy live config to an isolated test instance
2. Start container with new image → migration runs
3. Click through the UI manually → no 500s, no missing data

Only then is :latest updated.