Skip to main content
An ephemeral tenant is a short-lived, auto-expiring tenant scoped to a workspace. Each one is a real, database-isolated environment with its own database, environment variables, and configuration — but it deletes itself when its timer runs out. Spin one up for a pull-request preview, a CI run, or a throwaway experiment, and let it clean itself up.
Building only inside the Xano product today? Ephemeral tenants are created from the CLI, so you’ll need it set up first. See Build from your Local Agent to get started with agentic development — installing the CLI, connecting the Developer MCP, and pulling your workspace — then come back here.
Ephemeral tenant vs. sandboxBoth give you a database-isolated place to push and test changes, but they solve different problems:Use a sandbox for personal, review-driven iteration; use ephemeral tenants when you need several disposable environments at once or an environment that tears itself down.

​
Use Cases

Agentic development

Give an AI coding agent somewhere to push, run, and verify its work — several agents at once, each in its own tenant, none of them touching your live workspace.

CI/CD and PR previews

Create a fresh environment per pipeline run or pull request, test against real records and environment variables, then share a read-only preview link. It expires on its own, so there is no cleanup step.

Experiments and PoCs

Build a proof of concept locally, then push it to a real running environment to see whether the idea holds. The timer deletes it when you’re done — nothing to tear down, nothing left behind in your workspace.

​
Create

Create an ephemeral tenant with a display name. The workspace is required — pass -w or set one in your profile. The command prints the new tenant’s name and expiry. Use -o json for the full response.
--expires-hours is capped at 24. There is no non-expiring ephemeral tenant — for a long-lived environment, use a regular tenant or workspace instead.

​
List

List the ephemeral tenants in the current workspace, or across every workspace you can access with --global.

​
Get & Edit

Retrieve one tenant’s details, or update its display name and description. edit changes only the display name (--display) and description (-d); it does not extend the expiry. Both commands accept -w and -o.

​
Pull & Push

Pull an ephemeral tenant’s content down as local XanoScript files, or push local files up to it. This works the same way as workspace pull & push, using the multidoc format — but targets the ephemeral tenant. Unlike a regular tenant, an ephemeral tenant does accept a direct push.

​
Pull

​
Push

By default, only changed files are pushed (partial mode). Push shows a preview and prompts for confirmation before applying anything — always run --dry-run first to inspect the change.
In CI, combine --force (skip the interactive prompt) with --wait. With --wait, the command blocks until every auto-deployed microservice is ready and exits non-zero if any fails to deploy or the wait times out — so a failed deploy fails the pipeline step instead of passing silently. --wait is ignored with --dry-run.
--truncate empties tables before importing, and --no-transaction disables the rollback safety net. Use them deliberately, and preview with --dry-run first.

​
Impersonate

Open the ephemeral tenant’s dashboard in your browser, or print the URL for scripting.
--guest --url-only is the pairing for a per-PR preview link: it returns a read-only URL you can post as a comment so reviewers can browse the environment without being able to change it.

​
Static Hosting

An ephemeral tenant can host static sites, scoped to that tenant. These commands mirror xano static_host but take the tenant name as the first argument.
Static hosting is currently available for local tenants. Remote (tier2/tier3) tenants are not yet supported and will return an error.

​
Delete

Delete an ephemeral tenant immediately, rather than waiting for it to expire. Add -f to skip the confirmation prompt (for CI/CD).
Deleting an ephemeral tenant destroys all associated infrastructure and data. This cannot be undone. (An ephemeral tenant is also destroyed automatically when its --expires-hours window elapses.)

​
Typical Workflow

A common pattern for standing up a disposable environment, verifying it, and sharing a preview:
1

Create the environment

Note the tenant name it returns — you’ll use it below.
2

Push your code and wait for deploy

3

Test against the live environment

The tenant is now serving real API requests. Point your test suite or API checks at its endpoints, exactly as you would any deployed environment.
4

Share a read-only preview

Post the returned URL for reviewers. The tenant tears itself down when its timer expires — no cleanup step required.
An ephemeral tenant is for verifying a change, not shipping it — nothing is copied from a tenant to production. Once an experiment proves out, promote it through your normal release process: push the same local files back to a workspace, or deploy them to a tenant, depending on how your team ships. See CI/CD for the end-to-end release flow.