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

# Across workspaces

> Ship one release to another workspace or another Xano instance: sign in with a credential profile for each, copy the release with xanosdk release transfer, then promote it at the destination.

A release is stored in the workspace it was cut in. To ship it to a second workspace, or a
workspace on another Xano instance, copy it there with `release transfer`, then promote it at
the destination as you would at home. The bytes that passed your tests are the bytes that land.

## Sign in to each workspace

One credential addresses exactly one instance and one workspace. Keep one **profile** per
destination:

```bash theme={null}
npx xanosdk login --profile prod     # sign in and pick the destination workspace
npx xanosdk profile list             # every profile, with the default and the active one marked
```

For automation, store a meta API token under a name instead. The token is read from stdin or
asked for, never taken as a flag:

```bash theme={null}
printf %s "$PROD_META_TOKEN" | npx xanosdk profile add prod --instance https://your-instance.xano.io --workspace-id 3
```

`--profile <name>` (or `-p`) on any command acts as that profile for that one run.

## Copy the release, then promote it

```bash theme={null}
npx xanosdk release transfer v1.4.0 --to-profile prod --dry-run   # is it already there?
npx xanosdk release transfer v1.4.0 --to-profile prod             # copy it
npx xanosdk promote v1.4.0 --profile prod                         # land it on a new Xano branch there
```

The run's own credential is the source and `--to-profile` is the destination. A profile bound
to the same instance and workspace is refused.

`release transfer` copies the archive and nothing else: no compile, no Xano branch, nothing
lands. Everything [Promote and go live](/ship/promote-and-go-live) says applies at the
destination, and so does [Tenants](/ship/tenants):

```bash theme={null}
npx xanosdk tenant deploy prod v1.4.0 --profile prod
```

## Safe to re-run

A transfer decides "already there" by content: the sha256 of the release archive, which is the
same on every host that stores it. Never by name or size.

| The destination holds | Result | `--dry-run` answers |
| - | - | - |
| A release with the same content | Reused. Nothing is imported, and the run reports `completed: yes`, `reused: true`. | `present: identical` |
| A **different** release under that name | Refused (`SDK_RELEASE_NAME_TAKEN`, exit `2`). Releases are never replaced; `conflictsWith` names the holder. | `present: conflict` |
| Neither | Imported, read back, and hashed again. | `present: absent` |

The copy is stored under the release name recorded inside the archive. A transfer never deletes:
if what landed does not hash to what was sent, it exits `2`, and `residue` names the import and
the `release delete` that removes it. If the run exits `9`, run the dry run again before
anything else; it reports whether the copy is there.

Env values do not travel with a release. Set them on the destination with `env set` and the
same `--profile`. See [Env and secrets](/build/env-and-secrets).

## Next

[CI/CD](/govern/ci-cd): run the release flow from your pipeline.


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