Skip to main content
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:
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:
--profile <name> (or -p) on any command acts as that profile for that one run.

Copy the release, then promote it

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 says applies at the destination, and so does Tenants:

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

Next

CI/CD: run the release flow from your pipeline.