Zum Hauptinhalt springen

Configuration Backups & Version History

Your app's configuration is real authoring work: views, controls, forms, tools, zones, action plans, knowledge, and session templates. The Backups tab (Backoffice, Apps → your app → Backups) captures all of it as one restorable snapshot, keeps a version history, and lets you roll back a bad change in two clicks.

A backup covers the whole app, across every domain registered on it.

Take a backup​

Click Back up now, optionally with a label ("before Q3 cleanup"). Rules of thumb:

  • Back up before any large change: a bulk re-authoring session, an AI-assisted repair run, a selector migration after a host-app redesign.
  • Labels are for your future self. "before removing legacy tools" beats an unlabeled row six months later.
  • Taking a backup when nothing changed does not clutter the history: Appilot detects the unchanged state and keeps the existing entry instead of storing a duplicate.

Backups also happen automatically: every restore first saves the current state as a "Before restore" entry. A restore is never a one-way door. If you restore the wrong backup, restore the automatic snapshot and you are back where you started.

Download and upload​

Download (current config or any history entry) saves a <app>-config-<date>.appilot.json file: a readable JSON document you can keep off-site, attach to a change ticket, or commit to your own repository.

Credentials are never inside the file. Tools that use a stored API secret export a reference to the credential, not the credential itself, so the file is safe to store and share. After restoring such a bundle into a fresh app, re-enter those secrets once in the tool's credential section.

Upload & restore takes a previously downloaded file and walks the same restore flow described below. This is also how you move a configuration between environments (e.g. staging to production): download there, upload here. If the two environments use different hostnames, edit the domain values in the file first; the import refuses unknown hostnames instead of guessing.

Restore​

Restoring always shows you the consequences before anything happens:

  1. Review the comparison. Appilot compares the backup against the current configuration and shows what would be created, updated, and deleted, per entity, plus any quality findings.
  2. Confirm. A restore replaces the configuration to match the backup exactly, including the deletions shown. The confirmation is explicit and the current state is saved automatically first.
  3. If someone else changes the configuration while you are reviewing, the restore stops, refreshes the comparison, and asks you to review again, so you never apply a diff you have not seen.

If the backup would introduce critical quality findings (for example, an old backup that predates newer validation rules), the restore is blocked until you explicitly tick "Restore anyway". The findings stay visible either way.

Automation and CI​

Everything the tab does is available over the API with a service token: a nightly GET /config/export with a config:read token gives you off-site backups in whatever storage you already trust. AI agents connected through the Appilot MCP server can use the same capability via the export_config and import_config tools, including safe, dry-run-first rollbacks.