> ## 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.

# Where code goes

> Every command that writes your backend somewhere, the target it writes to, and what the write does there: replace, merge, or add a new Xano branch, with tables shared by every Xano branch and env values added but never overwritten.

Each command that writes your backend names one target, and each target takes the write in one
of three ways: it is **replaced**, **merged into**, or given a **new Xano branch** beside what
it serves. Read this table before you run a command against anything real.

| Command | Target | What the write does |
| - | - | - |
| `npm run xano:deploy` | The Xano Engine on your machine | **Merge** (the script passes `--keep-data`): code and schema land, rows stay. |
| `npx xanosdk deploy ./xano/index.ts --ephemeral` | This project's ephemeral | **Replace**: tables are recreated and seeded again. `--keep-data` merges instead. |
| `npx xanosdk release create v1.4.0` | A release record in your workspace | **Reads** the source and stores a release. Nothing is written to the source. |
| `npx xanosdk promote v1.4.0` | Your workspace | **New Xano branch**: lands on a branch of its own. Live is untouched until you set it live. |
| `npx xanosdk tenant deploy prod v1.4.0` | A tenant | **Replace**: the tenant serves exactly the release. Tables the release lacks are dropped with their rows. Static hosting is kept. |
| `npx xanosdk deploy ./xano/index.ts --to workspace` | The live Xano branch of your workspace | **Merge**: adds and updates objects. Deletes only with `--prune`. `--branch <label>` lands on a new Xano branch instead. |
| `npx xanosdk deploy ./xano/index.ts --to tenant:prod` | A tenant | **Merge**, as above. |
| `npx xanosdk release transfer v1.4.0 --to-profile prod` | A release record in another workspace | **Copies** the release. Nothing lands. |
| `npx xanosdk publish ./frontend/dist --to workspace` | The static host | **Replace** the frontend only. No backend import. |
| `npx xanosdk env set STRIPE_KEY --to workspace` | One env var | **Sets** that one name. Every other name is left alone. |

The first two are your development loop. Everything from `release create` down reaches
something real, and every one of those commands names its target on the command line: a bare
`deploy` never reaches your workspace or a tenant.

## Replace, merge, or a new Xano branch

* **Replace** makes the target hold exactly what you sent. Anything it held that you did not
  send is gone. An ephemeral is replaced on every deploy without `--keep-data`, and a tenant is
  replaced on every `tenant deploy`, including an API that an earlier `deploy --to tenant:<name>`
  merge added.
* **Merge** writes what you send over what is there and leaves the rest alone. Objects are
  added and updated. Nothing is deleted unless you ask with `--prune`, and `--prune` deletes
  only what this project landed on that target (see [Merge path](/ship/merge-path)).
* **New Xano branch** is what `promote` does. The release lands on a Xano branch of its own,
  named after the release, and the live Xano branch keeps serving. Nothing serves the new
  branch until `--set-live` or `xanosdk workspace branch set-live`. A promote never deletes an
  object.

`deploy --to workspace --replace` is the exception to all of the above: it wipes the whole
workspace, every Xano branch included, before it imports. [Merge path](/ship/merge-path)
covers when it is refused.

## Tables are shared by every Xano branch

A Xano branch holds logic: API groups, queries, functions, agents and toolsets. **Tables and
microservices are not per branch.** Every Xano branch in a workspace reads the same tables and
the same rows.

So a table change reaches live the moment it lands, whichever Xano branch it lands on, and
deleting that branch does not undo it. `promote` and `deploy --to workspace --branch` refuse a
release that alters a table (`SDK_SHARED_SCHEMA_CHANGE`, exit `2`) until you pass
`--allow-shared-schema-changes`. New tables and new columns are additions and pass without the
flag. Switching back to an earlier Xano branch restores logic, never a dropped column or its
values. [Schema changes](/govern/schema-changes) covers how to change a table safely.

## Rows

| Write | Rows already in the target |
| - | - |
| Deploy to an ephemeral (no `--keep-data`) | Replaced by the seed rows your project declares. |
| `--keep-data`, `promote`, `deploy --to` | Kept. `deploy --to --seed` writes the seed rows by id. |
| `tenant deploy` of a release without rows | Kept for every table the release carries. Tables it does not carry are dropped. |
| `tenant deploy` of a release cut with `--seed` | Replaced, for each table the release carries rows for. |

A release carries rows only when you cut it with `--seed`. See [Releases](/ship/releases#what-a-release-carries).

## Env values are added, never overwritten

A deploy to an ephemeral replaces its env set. `promote`, `tenant deploy` and every merge are
**add only**: a name the target already holds keeps the target's value, so a release cut from
dev never overwrites production's secrets. (`deploy --to workspace --replace` is the exception,
since it rebuilds the workspace.) To change a value on your workspace or a tenant, set it there
with `xanosdk env set`. [Env and secrets](/build/env-and-secrets) has the full table.

## Next

[Releases](/ship/releases): cut the release that `promote` and `tenant deploy` land.


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