Config Transfer

Config Transfer lets you move an OttoFMS server's configuration to another OttoFMS install without needing OS-level access to either machine. You export an encrypted bundle from the source server and import it on the destination server, carrying over settings like offsite remotes, webhooks, MCP servers, and API keys so the new server behaves the same as the old one.

You'll find the "Config Transfer" card in Settings > OttoFMS Config.

When to use it

Config Transfer is the recommended way to carry your configuration forward whenever you stand up a new OttoFMS server — for example, when migrating to new hardware, rebuilding a server, or setting up a disaster-recovery standby. See Migrating OttoFMS to a New Server for the full migration workflow.

What's included

When you export a bundle, you choose which categories of configuration to include:

• App settings and API Keys — general settings, Data API Keys, Admin API Keys, and OAuth clients
• Offsite Remotes — your offsite backup configuration and backup schedules
• Webhooks
• MCP Servers and Tools
• Build & Deployment history
• Ottomatic Projects — project snapshot history (JSON metadata only; see note below)
• File Notes
• Developer Tool history

All categories are selected by default, and you can uncheck any you don't want to carry over. Secrets (like stored API keys and offsite credentials) stay encrypted within the bundle — OttoFMS never decrypts them during export.

What's excluded

A few things are intentionally left out of every bundle:

• Your OttoFMS license — you'll need to license the destination server separately.
• The FileMaker admin credentials used to log into the console — you'll sign back in on the new server after import.
• The source server's hostname — this prevents the new server from being misconfigured to point at the old one.
• Hosted FileMaker files and on-disk build/backup files. Build & Deployment history and Developer Tool history carry over as metadata only, since the underlying build archives and log files aren't included. Ottomatic Project snapshots carry over as JSON manifests only — the actual file clones and XML exports are not included, so imported snapshots aren't redeployable on their own.
• Runtime-only data like in-progress background jobs and short-lived login/authorization state, since these wouldn't make sense to replay on another server.

Exporting a bundle

1. Open the "Config Transfer" card in Settings > OttoFMS Config and click Export configuration.
2. Choose which categories to include, then click Generate bundle.
3. OttoFMS generates a one-time key and shows it once.

4. Copy the key somewhere safe, then click Download bundle to save the encrypted bundle file.

Importing a bundle

1. On the destination server, open the "Config Transfer" card and click Import configuration.
2. Select the bundle file and enter the one-time key you saved when it was exported.
3. Click Preview import. OttoFMS decrypts the bundle and shows a dry-run report of exactly what will happen — which categories will be imported, which existing items will be overwritten versus newly created, and anything you should double-check afterward — before anything is changed.
4. Review the report, then click Apply import to commit the changes.

Conflicts and overwrite behavior

During the preview, OttoFMS matches incoming items against what already exists on the destination server. Items that match an existing record (for example, a webhook with the same URL, or a setting with the same name) are marked to be overwritten; everything else is marked to be created. Existing data outside the categories you chose to import is left untouched.

A few categories have special handling worth knowing about:

• Offsite Remotes: importing this category fully replaces the destination server's rclone configuration file rather than merging it. Any offsite remotes that only existed on the destination server are removed. The previous file is automatically backed up alongside the new one before it's overwritten, and you should verify each remote still connects successfully after import, since paths can be machine-specific.
• MCP Servers and Tools: servers are matched by slug — a server with the same slug is overwritten, and others are kept. Imported MCP servers still need their referenced FileMaker files and scripts hosted on the destination server for the tools to work.
• Build & Deployment history and Developer Tool history: if the destination server already has history in these categories, importing replaces it entirely rather than merging it in.
• Admin API Keys: keys with the same key value are overwritten; others are kept.

After import, double-check any settings that identify the server itself (like the server nickname or environment tag), since those values carry over from the source server and likely need updating for the new one.

Version compatibility

If you import a bundle that was exported from a newer version of OttoFMS than the destination is running, OttoFMS will warn you about the version mismatch during the preview step so you can review the incoming data more carefully before applying it.