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

# Deploy to Xano

> How a backend you built and ran on the Xano Engine reaches production on Xano: test it on an ephemeral, cut a release, then promote it to your workspace or deploy it to a tenant.

Write with AI. Run locally. Deploy to Xano. This section is the last step: getting the backend
your agent wrote, and you ran on the Xano Engine, into production on Xano.

Production always runs a **release**: a stored, named copy of a backend that came up and
answered on Xano's cloud. You cut it once, and the same release lands on your workspace, a
tenant, or a second workspace, as often as you need.

```bash theme={null}
npx xanosdk deploy ./xano/index.ts --ephemeral --test   # 1. deploy to an ephemeral and run its tests
npx xanosdk release create v1.4.0                        # 2. cut a release from that ephemeral
npx xanosdk promote v1.4.0                               # 3. land it on a new Xano branch of your workspace
npx xanosdk tenant deploy prod v1.4.0                    #    ...or replace what a tenant serves with it
```

```mermaid theme={null}
flowchart LR
  E["Xano Engine<br/>npm run xano:deploy"] --> T["Ephemeral<br/>deploy --ephemeral --test"]
  T --> R["Release v1.4.0<br/>release create"]
  R --> P["New Xano branch<br/>promote"]
  P --> L["Live<br/>--set-live"]
  R --> TD["Tenant<br/>tenant deploy"]
  R --> X["Another workspace<br/>release transfer"]
```

The Engine and the ephemeral are the same backend, one on your machine and one in Xano's cloud.
A release is cut from the cloud one, which is why the ephemeral step is there.

<Note>
  No Xano account yet? [Connect to Xano](/start/connect-to-xano) takes the quickstart project to
  its first deploy to an ephemeral. Start there, then come back.
</Note>

## Start with where code goes

Every command in this section writes to a different place, and each one writes differently:
an ephemeral is replaced, a workspace gets a new Xano branch, a tenant is replaced, a merge
adds and updates. [Where code goes](/ship/where-code-goes) puts all of them in one table.
Read it before you run anything against a real target.

## Pick your path

* **One workspace, which is production.** Cut a release and promote it:
  [Releases](/ship/releases), then [Promote and go live](/ship/promote-and-go-live).
* **Tenants for dev, stage and prod.** Cut a release once and deploy it to each tenant:
  [Tenants](/ship/tenants).
* **Several workspaces or instances.** Copy a release across, then promote it there:
  [Across workspaces](/ship/across-workspaces).
* **No releases.** Merge a local build straight into the workspace or a tenant, with a preview
  first: [Merge path](/ship/merge-path).

Two pages apply whichever path you take. [Source of truth](/ship/source-of-truth) settles
whether your repo or your workspace holds the real backend. [Shipping
workflow](/ship/shipping-workflow) lays the whole flow out for a team, from a git branch to
production.

Going back is covered under Govern: [Rollback and recovery](/govern/rollback-and-recovery).

## Next

[Where code goes](/ship/where-code-goes): what each command writes, and where.


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