npx xanots deploy.
Two things come from the connector, and they are what make the flow work:
- Lovable preloads the XanoTS knowledge files into the agent’s context, so it knows XanoTS exists and reaches for it rather than Supabase or Lovable Cloud.
- Lovable’s connector gateway holds your Xano OAuth token and injects it when the agent mints a CLI credential. The agent never sees that token, and there is no key to paste.
Using Bolt instead? It has no connector gateway, so the same capability arrives over MCP
with an explicit tool surface — see Bolt.
Install the connector
1
Add Xano from Lovable's integrations
Find Xano in Lovable’s connector list and install it into your project.
2
Authorize
Sign in to Xano and approve the connection. The connector represents your authenticated
Xano account, and the instance and workspace you pick are what every later deploy is
bound to. Reconnect to target a different workspace.
3
Check it took
Ask the agent which Xano account it is connected to. It has one permitted diagnostic —
GET /api:meta/auth/me — which distinguishes “the connector is not authorized” from
“Xano is unreachable”.How a deploy runs
The agent authors your backend as XanoTS defs, then mints a credential immediately before running the CLI:XANO_META_TOKEN is the secret, and it is short-lived by design — 600 seconds by
default. It is passed to that one process and discarded: never written to .env, project
source, Git,
or Lovable project secrets. A run that fails on authentication is fixed by minting again,
not by asking for a longer lifetime. (ttl requests a different one, in seconds, clamped to
60–3600; expires_in reports what was actually granted.)
instance_url and workspace_id are not secrets and are safe to write into project
configuration.
The CLI is the only way in
Exactly two Xano endpoints are called through the connector —xanots/cli-token to mint the
credential, and auth/me as a diagnostic. Everything else goes through the XanoTS CLI: no
direct meta-API calls to list objects, read schema, create tables, or apply changes.
That is not ceremony. A change made through a direct API call is not described by your
XanoTS source, so the next deploy overwrites it or conflicts with it. The CLI is what keeps
the code the source of truth.
For the same reason, a failed mint is a stop, not a puzzle. The agent is told to report the
status and body rather than retry variations of the path, probe other endpoints, or fall back
to another way of getting a Xano credential — a failure there means the connector is not
authorized, and that needs you.
Ephemeral by default
A deploy goes to an ephemeral environment unless you say otherwise — a disposable environment, created or refreshed on each run, with its own URL and its own database, expiring on its own. Nothing that already exists is touched.
A release merges into your real workspace and overwrites what is live there, so it should
only ever happen because you asked for it. Watch for a
package.json script named deploy
that actually performs a release — that is not the right default for “just deploy this”.
Pointing the frontend at the backend
Lovable serves the frontend itself, so nothing injectswindow.XANO_HOST the way Xano’s own
static hosting does. Set the backend
URL as a build-time environment variable in the Lovable project — on a Vite frontend:
url addresses the instance host
without the tenant segment. Build file URLs from the file’s path and the same HOST —
fileUrl(row.avatar, HOST) from @xanots/sdk. See
The typed frontend surface.