Skip to main content
Four commands are the whole loop. Here they are one at a time.
1

Sign in

OAuth in your browser — no API keys to copy around. The CLI refreshes tokens for you, and the target instance comes from your token rather than a flag.
On a remote shell, container, or Codespace — anywhere your browser can’t reach this machine’s 127.0.0.1 — add --paste. It prints the URL for you to open anywhere, and you paste the redirect back. See Signing in & deploying.
2

Scaffold

init writes a complete project: a Vite frontend under frontend/ (React 19 + shadcn/ui by default, or SvelteKit with --framework svelte), a XanoTS backend under xano/, and the xano:export / xano:deploy scripts already wired.
In a terminal it asks two questions — framework and AI instruction files — each with a default. The theme is a flag, not a question:
The starter backend is empty but already compiles and deploys — grow it from the walkthrough in xano/EXAMPLE.md. For the flags, presets, theming, and add-ons, see The scaffolded project.
3

Build the frontend

4

Deploy both

One authenticated call ships your database schema, your APIs, your functions and triggers, and your compiled web app.

​
The dev loop

Change your code and run step 4 again; the environment refreshes in seconds. The deploy bakes the backend URL into your build as window.XANO_HOST, so the frontend never needs to know it ahead of time — read it with a build-time fallback:
Deploying again keeps the backend URL; the frontend one changes, because a deploy is a full replace and clears the environment’s static hosting along with its workspace. Hand out the URL from the latest run.
Signing in & deploying covers the injection rules, serving stored files, and headless CI runs.

​
Wiring it by hand

Skip init — npm install @xanots/sdk, write your workspace in xano/index.ts, and steps 1 and 4 are unchanged. The entry must be an ES module (XanoTS defs are ESM-only), and a TypeScript entry wants tsx installed (npm i -D tsx) — the CLI picks it up automatically.
Node’s own type stripping is not enough on its own: it loads a .ts file but does not remap the ./x.js specifiers a workspace uses to import its own modules, so anything past a single file fails to resolve.

​
Testing what you deployed

The tests you author — a tests entry on a query, function, or middleware, or a standalone workflowTest() — run against a deployed environment:
A failing suite exits 5, distinct from a crash, so CI can tell the two apart. To deploy and prove it in one step, xanots deploy ./xano/index.ts --test — a failing test exits 5 without retracting the deploy, so the environment is live either way.