> ## Documentation Index
> Fetch the complete documentation index at: https://sdk.docs.xano.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Source of truth

> Decide whether your git repository or your Xano workspace holds the real backend, ship from that side only, and bring an emergency fix made in the Xano editor back into git with xanosdk pull.

A backend can be changed in two places: in your project's TypeScript, and in the Xano editor on
your workspace. Pick one of them as the **source of truth** and ship only from that side. Two
sources of truth means someone's work gets overwritten.

| | The repo is the source of truth | The workspace is the source of truth |
| - | - | - |
| Who changes the backend | You and your coding agent, in code | Your team, in the Xano editor |
| Where a change is reviewed | A pull request | A Xano branch, before it is set live |
| How a release is cut | From an ephemeral: `release create v1.4.0` | From the workspace: `release create v1.4.0 --from workspace` |
| What git holds | The backend itself | A copy, synced at each release |
| What ships to production | `promote` or `tenant deploy` of the release | `workspace branch set-live`, or `tenant deploy` of the release |

## 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 deploy` replaces everything on the tenant, so an edit there is gone at the next
  release.
* `deploy --to workspace` refuses to overwrite an object edited in Xano since your last deploy
  or pull (`SDK_WORKSPACE_CHANGED`, exit `2`). See [Merge path](/ship/merge-path#edits-made-in-xano-the-drift-guard).
* `promote` lands 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:

```bash theme={null}
git switch -c builder-fix
npx xanosdk pull workspace          # rewrite xano/ from what the workspace runs
git diff                            # should show only the fix
```

`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:

```bash theme={null}
npx xanosdk release create v1.4.0 --from workspace   # cut from what the workspace serves
npx xanosdk pull release:v1.4.0                       # bring that release into the repo
git add -A && git commit -m "v1.4.0"
git tag v1.4.0
```

Never `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](/ship/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:

```bash theme={null}
npx xanosdk workspace diff ./xano/index.ts
```

`changedThere` was edited in Xano, `changedHere` in your project, and `changedBoth` on both
sides, which you reconcile by hand. [Drift](/govern/drift) covers the baseline these come from
and how to keep both sides in step.

## Next

[Releases](/ship/releases): cut the release you ship.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.