Skip to main content
Each term has one meaning across these docs and the CLI’s own messages. The link after each definition goes to the page that teaches it.

​
Building

​
Def object

The unit you author: a table, endpoint, function, agent or other Xano object, written as a plain TypeScript object passed to a factory such as table() or query(). A project registers its def objects in xano/index.ts. How it works

​
Bundle

The JSON document the SDK compiles your def objects into, and the thing Xano imports. xanosdk export writes one; xanosdk deploy --bundle deploys one. A bundle can carry env values and documentation tokens in cleartext. Bundle format

​
xano.lock

The committed file, at xano/xano.lock, that pins each object’s identity and public URL slug across renames and environments. It also holds the landing records (landed) and the sync baselines (synced). Every build writes it. Git and merges

​
Route manifest

xano/routes.gen.ts: the generated file a frontend imports instead of the backend’s defs. It carries each endpoint’s verb and path, each realtime channel, and the request input types. It imports no SDK code, so it adds nothing to a frontend bundle. Typed frontend

​
Toolchain module

An installed add-on that extends the CLI rather than the workspace: it registers nothing in xano/index.ts, and instead contributes project files and runs hooks on export, deploy and route-manifest writes. Its config lives in the package.json "xanosdk" block. The other kind, a workspace module, ships def objects you register. Add-ons

​
Where a backend runs

​
Backend

A running Xano workspace-shaped thing a command can point at: your workspace, an ephemeral, a tenant, or a Xano Engine. A release is not a backend; it is an archive one can be stood up from. CLI overview

​
Xano Engine

The Xano backend running on your machine. A bare xanosdk deploy deploys to it, with no Xano account. It runs the same imports, statements and tests as an ephemeral. The Xano Engine

​
Ephemeral

A disposable Xano environment in Xano’s cloud, with its own URL and a lifetime of 1 to 24 hours. xanosdk deploy --ephemeral creates or replaces one. It is the usual source of a release. Ephemerals

​
Workspace

Your real Xano workspace on your instance: the one your login is scoped to, which holds your Xano branches, your releases and your tables. Connect to Xano

​
Xano branch

A copy of a workspace’s logic: its endpoints, functions and other objects. Tables are not branched; every Xano branch shares the workspace’s one set of tables. promote lands a release on a new Xano branch. Not the same thing as a git branch. Where code goes

​
Live Xano branch

The Xano branch your workspace serves. promote --set-live and workspace branch set-live switch it. Promote and go live

​
Tenant

A deployment under your workspace with its own URL and its own database, such as dev, stage or prod. Tenants are created in Xano; xanosdk tenant deploy replaces what a tenant serves with a release. Tenants

​
Backend selector

How a backend is spelled on the command line: workspace, ephemeral[:name], local[:name], tenant:<name>, or release:<name> where a command reads a release. One grammar for every command. CLI overview

​
Tracked backend

The backend a project last deployed to, an ephemeral or a Xano Engine, recorded in .xano/deployed.json. A bare command follows it. A deploy to the workspace or a tenant never becomes it, so a bare command cannot reach something real unasked. CLI overview

​
Releases

​
Release

A stored, named record in your workspace holding the archive of a backend that came up and answered. It survives the environment it was cut from, and it is the only thing promote and tenant deploy land. Releases

​
Cut

Making a release from a running source (an ephemeral, a Xano branch of your workspace, or a throwaway tenant) with xanosdk release create. A cut writes nothing to the source. Releases

​
Landing

Putting a release onto a real destination, through promote or a tenant deploy. A promote adds a Xano branch and never replaces what is live unless asked. A tenant deploy replaces what the tenant serves. Where code goes

​
Landing record

For each destination, the objects this project actually wrote there: the landed section of xano.lock for a workspace or tenant, and the uncommitted .xano/ephemeral.json for an ephemeral. It is the whole scope of --prune: an object the record does not name is never this project’s to delete. Merge path

​
Release transfer

Copying a release’s archive to another workspace or instance with xanosdk release transfer. It lands nothing; you promote the copy at the destination as a separate step. Across workspaces

​
Embedded name

The release name recorded inside a release’s archive. An imported copy is stored under this name, so it is the key for finding a transferred release. Across workspaces

​
Content digest

A release archive’s identity: a hash of its tar with every gzip layer removed. It is the one value every copy of a release shares, which is how a transfer decides a release is already there. Across workspaces

​
Name suffixing

What the platform does with a release name that is already taken: it stores the new release under that name plus a dash and four hex characters (v1.4.0-a019) and reports success. The CLI looks under both spellings. Releases

​
Operation outcome

The three-valued answer a release write gives to “does what you asked for exist?”: yes, no or unknown. Unknown means the write was sent and the answer was lost; it is settled by a read, never a retry. Exit codes and outcomes

​
Keeping code and workspace in step

​
Sync baseline

One content digest per object, recorded in xano.lock under synced for each workspace and Xano branch, each time the project and the workspace match (deploy --to workspace, a verified promote, pull workspace, init --from workspace). workspace diff uses it to say which side changed, and deploy --to workspace uses it to refuse overwriting an edit made in Xano. Drift

​
Easily confused

​
Deploy, release, promote, tenant deploy

  • Deploy writes your code to a backend: the Xano Engine (bare), an ephemeral (--ephemeral), or the workspace or a tenant (--to, the merge path).
  • Release (release create) cuts a stored archive from a running backend. It changes nothing that serves traffic.
  • Promote lands a release on a new Xano branch of your workspace. It adds; it replaces nothing live unless you pass --set-live.
  • Tenant deploy lands a release on a tenant and replaces what the tenant serves.
Where code goes puts every command that writes side by side.

​
Xano branch and git branch

A Xano branch lives in your workspace and holds logic only. A git branch lives in your repo and holds your source, xano.lock included. They are unrelated: promoting a release does not touch git, and merging a pull request does not touch your workspace. These docs always say “Xano branch” for the Xano kind.

​
Xano Engine and ephemeral

The same backend in two places: the Xano Engine on your machine, an ephemeral in Xano’s cloud. You develop on the Engine and cut releases from an ephemeral. The differences that change a command are listed once: where the Engine differs today.

​
The agent skill and knowledge()

The agent skill (xanosdk agent-skill install) teaches your coding agent, on your machine, how to build with the Xano SDK. Coding agents A knowledge() item is a def object in your backend: markdown that Xano’s own AI reads inside your workspace. It does not reach your coding agent. AI agents and MCP servers

​
Next