> ## 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. # Glossary > One plain definition for each term the Xano SDK docs and CLI use, from release, cut and landing to backend selector, sync baseline and Xano branch, each linked to the page that teaches it. 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](/start/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](/reference/bundle) ### `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](/govern/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](/build/typed-frontend#generate-the-route-manifest) ### 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](/build/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](/reference/cli/index#naming-a-backend) ### 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](/run/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](/run/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](/start/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](/ship/where-code-goes#tables-are-shared-by-every-xano-branch) ### Live Xano branch The Xano branch your workspace serves. `promote --set-live` and `workspace branch set-live` switch it. [Promote and go live](/ship/promote-and-go-live#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](/ship/tenants) ### Backend selector How a backend is spelled on the command line: `workspace`, `ephemeral[:name]`, `local[:name]`, `tenant:`, or `release:` where a command reads a release. One grammar for every command. [CLI overview](/reference/cli/index#naming-a-backend) ### 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](/reference/cli/index#the-tracked-backend) ## 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](/ship/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](/ship/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](/ship/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](/ship/merge-path#prune-deletes-only-what-this-project-landed) ### 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](/ship/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](/ship/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](/ship/across-workspaces#safe-to-re-run) ### 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](/ship/releases#name-a-release) ### 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](/help/exit-codes-and-outcomes#operation-outcome) ## 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](/govern/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](/ship/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](/ship/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](/run/xano-engine#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](/ai/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](/build/ai-agents-and-mcp-servers#knowledge) ## Next * A symptom and its fix: [Troubleshooting](/help/troubleshooting). * How the pieces fit: [How it works](/start/how-it-works). This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.