SITEMAP (IA DRAFT) · 2026-08-13HomePlatformOverviewBuild with AIUnderstanding LayerAutopilotObservabilityAPI BuilderMCP BuilderDatabaseDevelopersXanoTSSecurityTemplates ↗SolutionsTrust what AI builtPilot→ProductionLogic CentralizationLegacy Modernizationvs SupabaseEnterprisePricingLearnDocs · Academy · Blog — not drafted
XanoTS · The complete stack for AI-built software

Ship the whole app. Not just the backend.

One command scaffolds a typed backend, the frontend in the framework you pick, and a live workspace behind both. Tell your agent what to build, publish to a sandbox to validate, and promote when you're ready.

$ npx xanots init my-app --frontend-language react $ npx xanots deploy xano/index.ts

Two commands to get started. Declare your app logic and infrastructure in TypeScript. Everything runs in Xano.

SetupDevOpsGlue codeServers

Shipping an app is mostly not the app.

Building the product is easy. The hard part is everything under it: database, auth, permissions, infrastructure, deploys. The same setup, every project, before you have a single user.

XanoTS handles the setup. You focus on building what you want.

The same platform. Authored as TypeScript.

Xano runs the backend for 100,000+ builders — database, APIs, auth and scheduled jobs, with no servers to manage. XanoTS is that same platform, written as TypeScript.

[product shot: the XanoTS file tree in an editor, beside the running app]

Your app is now a file tree: type-check it, diff it, review it, hand it to an agent.

What you get

  • Managed Postgres, with no migrations to run.
  • An API runtime already running — endpoints answer on a URL the moment a deploy returns.
  • Hosting for the frontend, in the same command.
  • Environments you can branch, promote, diff and roll back.

What you don't

  • No instance to size.
  • No server process to keep alive.
  • No console step between scaffolding and deploying.
  • Nothing untested reaching production.
  • No TypeScript runtime — defs compile ahead of time; they don't execute per request.
[product shot: the visual canvas — an endpoint's function stack, read-only]

You build in your editor. The canvas is where everyone — your reviewer, your on-call engineer, you at 2am — sees, understands, and debugs what's actually running.

Everything Xano runs →

The whole loop, from empty directory to production.

01 · Scaffold

A workspace, not a starter kit.

The scaffold arrives complete: a typed backend under xano/, an app in the framework you asked for, and a live workspace already provisioned. There's no console step in the middle — you never leave the terminal to make the thing exist.

02 · Build

Your agent edits typed files.

Which is the thing agents are actually good at. Your agent works on a file tree with types around it, and the compiler answers back before you do.

03 · Publish

A live URL to validate against.

Publish to a sandbox. Your designer clicks a real URL and your PM files a real bug, and nothing about production changed while they did it.

04 · Promote

Ship what you reviewed.

What you promote is what you checked — the same defs, the same diff. Nothing gets rebuilt by hand on the way to production.

my-app/ ├─ xano/ the typed backend │ ├─ index.ts what gets registered and deployed │ ├─ tables/ schema │ └─ api/ endpoints, jobs, agents ├─ frontend/ the app, in your framework │ └─ src/ ├─ CLAUDE.md house rules your agent reads └─ package.json

One more file sits alongside these: xano.lock, which records object identities.

Six primitives. Everything you need — and nothing you don't want.

Infrastructure and logic, declared together. Each primitive is a typed def: the object it provisions and the logic it runs, in one object.

table()

Typed columns, indexes and seed rows, Postgres underneath.

query()

An HTTP endpoint: verb, path params, typed input, a stack, a response.

agent()

An LLM plus the tools it may call, invoked from any stack.

mcpServer()

Expose those same tools to Claude, Cursor, or any MCP client.

task()

A cron job that runs on Xano's schedule, not on a box you keep alive.

realtimeChannel()

Websocket channels with presence, replay and per-recipient rules.

Bring your frontend framework. Deploy it in the same command.

Every quickstart goes from nothing to a deployed app — frontend and backend together. Endpoints are plain HTTPS and JSON, so anything that speaks HTTP works. TypeScript clients get the types inferred from the defs — nothing generated.

ReactNext.jsVueNuxtSvelteAstroAngularSolidExpoFlutterSwiftPythonWeWebFlutterFlowWebflowRetool
Drive it with any coding agentClaude CodeCursorGitHub CopilotCodexWindsurfClineGemini CLIv0Replit

The frontend ships with the app — it isn't the star. The star is the backend behind it: typed, tested, and readable by everyone who has to trust it.

You don't have to be at your computer.

Running an agent locally means sitting with it. So it runs on Xano's infrastructure instead: post a task, and it builds in its own isolated sandbox while you're in a meeting or asleep. Nothing says one at a time — hand the queue three tickets, review three branches.

Triage from the tracker you already use

Post the issue to the API. GitHub Issues and Linear webhooks work as-is, and anything that can make an HTTP request works too.

Isolated by construction

Each task builds in an isolated sandbox with its own data, separate from production by construction. A task that goes wrong gets thrown away — it cannot reach production, because it was never pointed at it.

It comes back as a branch

The output is a diff and a live environment to check it against — the same review you'd give a colleague.

Held by the deterministic harness

The agent's work clears the same gates yours does — type checks, workflow tests, the release gate. Rules, not another model's opinion; the same checks, every run.

$ curl -X POST "$XANO_HOST/api:agents/task" \ -H "Authorization: Bearer $TOKEN" \ -d '{ "title": "Signup rejects valid + addresses", "body": "Reported by 3 users. See LIN-482.", "repo": "acme/store" }' task queued branch fix/signup-plus-addressing status ready for review

How the harness governs building →

See what it built. Then decide.

Everything you deploy lands as ordinary Xano objects, so the canvas shows the whole app: every endpoint, every workflow, every request traced to the step that ran. Your agent wrote it in the editor. Everyone reads it here.

Workflow tests run in the sandbox — your endpoints actually get hit, not mocked. Fail one, and you debug the draft with real request inputs. What ships is what you watched pass.

[product shot: an agent's branch open in the read-only canvas — workflow tests passing, one request traced to its step]

See what your backend is doing →

The same argument, from two directions.

Building alone

Ship the whole product yourself.

The fortnight of infrastructure between an idea and the first user disappears — without leaving TypeScript, giving up your repository, or maintaining a pipeline of your own.

  • Backend, frontend and hosting in one command.
  • Auth, jobs and file storage are one line each.
  • Nothing you deployed can page you at 3am.
Building together

Put the whole app in the pull request.

Authored as typed files, the app inherits every practice your team already runs. Review, blame and revert work the way they already do.

  • Schema and auth changes arrive as diffs.
  • CI gates: --strict, --frozen-lock, validate.
  • A sandbox to validate every pull request against.

Start from a module, not an empty file.

Each module is an npm package of typed defs — tables, endpoints, agents, MCP servers — that registers onto your workspace. Install it, deploy, and it's live with the rest of your app.

Auth @xanots/auth

Signup, login and session endpoints with a user table.

3 tables · 3 endpoints · 1 function

Chatbot @xanots/chatbot

A retrieval-backed chat agent with conversation history and an MCP surface.

2 tables · 3 endpoints · 1 function · 1 mcp server

Billing @xanots/billing

Stripe subscriptions, plans and a webhook that keeps entitlements in sync.

4 tables · 5 endpoints · 1 function · 1 background task

Storage @xanots/storage

Uploads, image variants and signed private files, with quotas per user.

2 tables · 4 endpoints · 2 functions · 1 background task

XanoTS defines an app that runs on Xano. That's the trade, stated plainly: you don't choose a deploy target, operate a runtime, or wire the pieces together — and what you build ships where Xano runs it, under the same governance, with the same 100,000+ builders' platform underneath.

How it works underneath →

100,000+ builders can't be wrong.

100k+

Builders on Xano.

3M+

Users served by a single Xano backend.

SOC 2 / ISO 27001

GDPR, HIPAA-ready.