Skip to main content
Static hosting lets you serve frontend assets (HTML, CSS, JavaScript, images) directly from Xano alongside your backend APIs. This is useful for single-page applications, marketing sites, documentation, or any static content that pairs with your Xano backend. The CLI manages static hosting as a full lifecycle: create a host, push versioned builds (from a directory or a zip), deploy them to the dev and prod environments, and pull builds back to disk. Each host has two environments, and builds are promoted into them with deploy.
Static host commands require a workspace ID, either from your profile or via the -w flag. Static hosts are referenced by name, and builds are referenced by ID (--build_id).

​
Managing Static Hosts

​
List Static Hosts

Each static host shows its name, ID, and domain (if configured). Use -o json for the full JSON response.

​
Create a Static Host

​
Get a Static Host

Inspect a single host — its description, git configuration, and the URLs deployed to its dev and prod environments.

​
Edit a Static Host

Update a host’s name, description, or git configuration. Provide at least one of --name, --description, or a --git-* flag.
Renaming a host changes its deployed hostname.

​
Builds

Builds are versioned snapshots of your static assets. Each static host can have multiple builds, letting you track deployment history and manage versions. You upload them with build push and promote them to an environment with deploy.

​
List Builds

Each build shows its name, ID, and status. Use -o json for full details.

​
Get Build Details

​
Push a Build

build push is the primary way to upload a build. Point it at a directory (-d, which the CLI zips for you) or an existing zip file (-f). If you omit both, it pushes the current directory. The build name is optional — when omitted it’s auto-generated from the current timestamp (e.g. 20260531-143022): You can also push an existing zip file directly: On success, build push reports the file count and upload size and prints the resulting static host URLs:
For builds that include a package.json, the build runs asynchronously on Xano after upload. By default the CLI waits for the build to finish and reports its final status. Pass --no-wait to return immediately after upload instead.
xano static_host build create is deprecated. Its zip-upload capability has been folded into build push — use xano static_host build push -f <file> instead.

​
Pull a Build

Download a build to disk. Select the build by ID (--build_id), the most recent build (--latest), or the build currently deployed to an environment (--env dev|prod). Exactly one of these is required. By default, build pull downloads the original uploaded source (including package.json). Pass --source built to fetch the compiled/served output instead.

​
Delete a Build

Delete a build permanently. This prompts for confirmation unless you pass --force.

​
Deploy

Promote a build to an environment. A host has two environments — dev and prod — and deploy points the chosen environment at a specific build. On success, deploy prints the resulting URL for that environment.

​
Migrate to v2 Hosting

migrate moves static hosts from the older v1 hosting to instance-managed (v2) hosting.
Instance-managed (v2) hosting serves your static sites from a fully containerized environment inside your Xano instance. It removes some of the external dependencies that made the original (v1) hosting less flexible for certain setups, giving you more control over how your frontend is served.
You can migrate a single host, a single environment of a host, or every v1 host in the workspace with --all. Use --dry-run to preview what would change without applying anything. Provide either a static host name or --all, not both.

​
Typical Workflow

A common pattern for deploying a frontend alongside your Xano backend:
Name your builds with version numbers so you can easily identify them later when listing builds. If you skip -n, the CLI assigns a sortable timestamp name automatically.