The repo is the source of truth
This is the default, and the flow the rest of this section describes: your agent writes the backend in TypeScript, you run it on the Xano Engine, and you ship a release. The workspace and every tenant are then outputs. Do not edit them in the Xano editor:- A
tenant deployreplaces everything on the tenant, so an edit there is gone at the next release. deploy --to workspacerefuses to overwrite an object edited in Xano since your last deploy or pull (SDK_WORKSPACE_CHANGED, exit2). See Merge path.promotelands logic on a new Xano branch from the release, so an edit on the old live Xano branch stops serving as soon as you switch.
Bring an emergency fix back into git
Sometimes a fix has to go straight into the Xano editor, on the live workspace. Bring it into git the same day, before the next release overwrites it:pull rewrites the files it decodes and keeps files you added. It lists what it will change
and asks first, and it refuses a dirty working tree. Open a pull request from the git
branch, and ship the fix as the next release.
The workspace is the source of truth
Some teams build in the Xano editor. Releases, tenants and rollback work the same way. Two things change: changes are made and reviewed on Xano branches, and you keep git in sync yourself, at every release:promote or deploy --to workspace from the repo when the workspace is the source of
truth. It makes git a second source of truth and overwrites the editor’s work. Shipping
workflow lays out the full team flow for both models.
See which side changed
workspace diff compares the workspace with your project and says which side moved since they
last matched:
changedThere was edited in Xano, changedHere in your project, and changedBoth on both
sides, which you reconcile by hand. Drift covers the baseline these come from
and how to keep both sides in step.