Back Up and Move an AI App
An AI app accumulates value over time: the models you wired up, the datasets you curated, the tasks you tuned and the evaluation results you produced. Two commands let you take all of that off an instance and put it back, either as a backup or on a different deployment.
The Whole App, in a Directory
lf dump writes an entire AI app to a directory:
lf dump --to ./my-app-dump # the app in the current context
lf dump --app airline-assistant -t ./my-app-dump # a specific appThe directory is created if it does not exist and overwritten if it does. What lands in it:
my-app-dump
βββ ai_app.yaml # the app itself, including its key_info and tags
βββ model_adapters/ # one YAML per entity
βββ models/
βββ dataset_generators/
βββ datasets/ # specs plus the sample data
βββ tasks/
βββ risk_scorers/
βββ evaluations/ # one bundle per evaluation run, results included
βββ policies.yaml # written only if the app has policies
βββ risk_policies.yaml
The evaluation bundles are the reason a dump is more than a config export: they carry the results, so a restored app shows the history it had, not an empty slate.
lf restore replays a dump onto the instance the CLI currently points at:
lf restore --from ./my-app-dumpRestore recreates the app under the key recorded in ai_app.yaml, and refuses to run if an app with that key already exists on the target instance. To keep a copy alongside the original, edit key (and usually display_name) in ai_app.yaml before restoring.
Evaluation bundles are restored one at a time, oldest first. If a single bundle fails, the error is reported and the restore continues with the rest - so a partially restored app is a possible outcome. Check the output rather than assuming success.
What About Secrets?
Secrets are tenant-scoped, not app-scoped, so they do not automatically travel with a dump. Three cases:
Same instance (backup and restore, or duplicating an app). The secrets are still there. The restored app resolves
<< secrets.NAME >>against them and everything works.Different instance, secrets recreated by hand. Create them on the target first with
lf secret add, using the same names. Restore then picks them up.Different instance, secrets carried in the dump. Pass
--with-secrets:lf dump --to ./my-app-dump --with-secretsThe dumped evaluation bundles then include secret values, and restore recreates them as secrets on the target. This requires admin permissions, and it puts credentials in a directory on disk - treat the dump like the credentials it now contains.
If a secret is referenced but neither present on the target nor carried in the dump, the affected evaluation bundle cannot be restored. If it is present on the target but not carried in the dump, the restored evaluation falls back to the targetβs value - which may differ from the one it originally ran with. That case is reported as a warning.
See Manage secrets for how secrets are declared and referenced.
One Entity at a Time
For everyday work you rarely need a whole dump. Every entity type can be exported on its own, which is the fastest way to get the canonical YAML of something created in the UI:
lf export app 'airline-assistant' -o app.yaml
lf export model 'openai$gpt-4-1-mini' -o model.yaml
lf export task 'refusal-check' -o task.yaml
lf export dataset 'hp-trivia' -o dataset.yaml -do data.csvOmit -o to print JSON to stdout. See lf export for the full list.
Retiring an App
Deleting an app removes it with everything inside it - entities, evaluations and results:
lf delete app 'airline-assistant'Take a dump first if there is any chance you will want the history back.
Provider Integrations
Provider credentials - the API keys behind lf add model -p openai/... - are configured per deployment, not per app, and are therefore unaffected by dump, restore and delete:
lf integration list # which providers are configured
lf integration add --provider openai --api-key $OPENAI_API_KEYSetting up each provider is covered in Integrations.