Backup files

Composer auto-creates several backup files alongside its working state. Most of them have no UI and no toggle — they happen unconditionally — and stay invisible until you need them. This page collects the full set in one place so you know what to reach for when something has gone wrong.

There is no single Settings tab for these — they're listed here as a recovery reference rather than as a tunable surface.

settings.bak

On every Composer Desktop launch, the loader copies settings.xml to settings.bak next to the executable before any other code reads or writes settings. The backup is unconditional and overwrites the previous one. Not user-configurable — there is no toggle and no path option.

When it helps:

• settings.xml becomes unreadable — a manual edit went wrong, an in-flight save was interrupted, or the file is otherwise corrupt. Restore by copying settings.bak over settings.xml and relaunching.
• A setting change produced unexpected behaviour — the previous launch's settings.bak still holds the prior values even after settings.xml has been overwritten with the new ones, so you can diff the two to see exactly what changed.

Because the file is overwritten on every launch, recovery is only possible until the next time Composer starts — restore (or copy aside) before relaunching.

apikeys.bak

Composer's HTTP API key file (apikeys.json, see HTTP API → Authentication) is similarly mirrored to apikeys.bak whenever the key file is successfully loaded. If apikeys.json is missing on a subsequent startup, the loader transparently restores it from apikeys.bak — so an accidental delete or a corrupt write doesn't lock external automation out of the API.

Like settings.bak, it lives next to the executable, has no toggle, and overwrites the previous backup on each refresh.

<projectname>.bak

When Automatically create project backups (AutoSaveProjectBackup, see General → Project load behaviour) is on, Composer Desktop runs a periodic timer that writes a rolling backup of the currently open project to <projectname>.bak next to the project file. The timer fires every ~5 minutes and writes only if the project has been modified since the last backup; the file is overwritten each time.

When it helps:

• The working .prj file is corrupt or saved with unintended changes — <projectname>.bak holds the project's state from up to ~5 minutes earlier. Open it from File → Open like any other project file, then Save As over the original.
• Composer was closed without saving — the .bak preserves the in-progress state at the last backup tick, so a recent edit isn't lost outright.

Because there is only one .bak per project (it rolls forward in place), it's a recent-state safety net rather than a history. For a longer trail of older versions — one snapshot per autosave interval, retained for days — see the Autosave tab.

Dated archive in BackupDirectory

When Backup directory (BackupDirectory, see General → Directories) is configured to an existing folder different from Projects directory, Composer Desktop writes an additional dated copy of each project on File → Save. The destination is <BackupDirectory>\<MachineName>\<yyyy-MM-dd>_<projectname>.prj — one file per host, per day, per project (same-day saves overwrite the same dated file).

When it helps:

• You want a per-day archive surviving the working file — the working .prj may be overwritten or its containing folder deleted, but the dated copies in BackupDirectory accumulate independently.
• The archive should live on a separate drive or network share — set BackupDirectory to a path on the safer storage and Composer mirrors each saved project there for free.
• You want to compare a current project against the version it was a week ago without rummaging through the host-local autosave history.

Empty (the default) skips the dated archive entirely. The dated archive is independent of <projectname>.bak — they're separate mechanisms with different triggers (save vs. timer) and destinations (configured archive vs. project's own folder).

Quick reference

For the deeper history trail (every snapshot, retained for days, with a UI to restore from), see the Autosave tab — that's a different mechanism with a different file format and is not listed above.