FAQ

#What is Xeer, in one sentence?

A full-stack framework where you declare your app's shape in one manifest, write typed server functions and a reactive client against it, test it with a runner that ships in the box, and deploy it to a real URL with one command.

#Can I get an account?

Xeer is in closed beta, and deploying needs an invitation.

Everything local does not: xeer new, xeer dev, xeer test, xeer build, and xeer preview need nothing but Node.js — no account, no network, no credentials. The framework, the compiler, the dev server, and the test runner are MIT-licensed and run entirely on your machine. You can build a complete app and never sign in.

If you run xeer auth login without an invitation, you get a page saying so, nothing is created, and the terminal stops waiting rather than hanging until the request expires. To ask for one, open an issue or a discussion on GitHub.

#Do my app's users need a Xeer account?

No. The closed beta gates deploying, not visiting. Anyone can use an app you deployed.

In fact they need no sign-in at all to start: every visitor to a Xeer app gets a verified, stable identity on their first request, so your app can own data per user immediately. If you add sign-in, the only provider that ships today is Google — and signing in links the visitor's existing identity, so rows they created beforehand stay theirs. See Auth.

Your builder account and your app's users are two entirely separate systems. Signing in to your own deployed app makes you an ordinary user of it, with an id unrelated to your builder account.

#Do I have to use the hosted platform?

To deploy with xeer deploy, yes — that is what it deploys to. There is no self-hosting path today, and we would rather say so plainly than imply one exists.

What you keep regardless: your source, your data, and a way out. xeer export writes your app's records as a readable, diffable document with the schema that produced them, from a deployed app or a local one. Your build artifacts are content-addressed and inspectable. Nothing about your project is stored in a format only we can read.

#What is it actually running on?

Xeer apps run on Cloudflare's infrastructure. You never configure it, never see a dashboard, and never hold a Cloudflare credential — the CLI talks to Xeer's control plane and nothing else, and your app's database, sign-in, and live-update streams are all provided by the framework. But you deserve to know where your code executes, so: that is where.

Practically, it means your app runs close to your users rather than in one region, cold starts are not something you tune, and your database lives with your app rather than a network hop away.

#Which Node.js version?

22.12 or newer. The CLI checks at startup and prints a clear error otherwise. xeer doctor reports your version and platform support.

#Is it TypeScript-only?

Effectively yes. The generated types are the point — your manifest types your database, your server types your client, and your server types your tests. Plain JavaScript would run, but you would be giving up most of what the framework is for.

#Why is the package called @impetik/xeer?

npm's automated anti-typosquatting check rejected the unscoped name xeer as too similar to existing packages. The installed command is still just xeer.

npx @impetik/xeer <command> works — npx resolves the scoped package and runs its xeer binary. What does not work is dropping the scope: a bare npx xeer looks for a package literally named xeer, and npx x is an unrelated package entirely.

#React, or Preact?

Preact, with JSX configured for you. In practice that means components, hooks, and class instead of className. Use preact/hooks for anything beyond the useState that @impetik/xeer/client re-exports.

#Can I use my own UI library, or Tailwind, or a component kit?

package.json is an ordinary package.json and you can add whatever you like. Xeer owns the compile-and-deploy path and the platform imports; it does not own your dependency list or your styling. There is no bundled CSS framework and no opinion about how your app should look.

#Why can't I write the query I want?

Because a where filter must match a declared index prefix, and there is no orderBy, no comparison operator, and no offset pagination. See the table API.

The trade is deliberate: every query the API can express is one an index already serves. There is no accidental full-table scan to discover in production. When you need a different shape, you add an index to the manifest — a reviewable change to a checked-in file.

If your app needs relational joins, window functions, or full-text search, Xeer is not the right tool today, and it is better to know that now.

#Where do I put an API key?

xeer env set NAME value, then read it as ctx.env.NAME in a handler. Values are stored per environment, encrypted at rest, and injected into your deployed app. They cannot reach the browser: client code cannot import server code, and the compiler enforces it. See Environment variables and secrets.

#How do live updates work, and can I turn them off?

Every query records which tables it read and every mutation reports which it wrote, so a commit refreshes exactly the queries that care — across tabs and across users. There is nothing to configure and nothing to switch off; a query that is not mounted does not refetch. See Live updates.

#Is there file or blob storage?

Yes. Declare the storage capability and ctx.storage appears in your server handlers: put, get, head, list, delete over an object store that belongs to your app alone. No bucket name, no credential, no region — and it is fully emulated by xeer dev. See Capabilities → storage.

The one thing to plan around: there is no signed-upload URL. A browser uploads by POSTing to one of your endpoints, which means an upload is bounded by your requestBytes budget — 4 MiB at most. An object larger than that has to be assembled server-side. That is a real limit today, not a detail we are glossing over.

#Are there limits during the beta?

Yes, and they are hard caps rather than billing. The starting allowances are 10 apps per account, 30 deploys per hour, and 200 per day. Preview deploys, promotions, and rollbacks all count as deploys, because they all upload. Your app itself is bounded by its manifest budgets, which you control.

#Is preview a copy of production's data?

No, and this is worth being clear about. A preview deployment is a separate instance with its own data. It cannot read or corrupt production's records, and it starts empty and is replaced by your next preview deploy. Treat it as a place to look at a build, not a staging copy of your database.

#What happens if a deploy goes wrong?

Nothing your users can reach changes until a deploy passes its readiness gate: platform health, assets, and one authenticated request. A build that serves static files but cannot answer a real request fails the deploy rather than replacing what was working.

If something gets through anyway, xeer rollback <artifactId> redeploys a previous version by its content address, and xeer disable takes the app offline in one request while you work out what happened. See Deploy.

#Can I take my data out?

xeer export my-app --out backup.json

Schema plus every record, as readable JSON. From a deployed app you own, or from your local dev database with --state dev.

#Is it stable? Can I build something real on it?

It is a 0.x release in closed beta, and the honest answer is: build something real, but expect the framework to change under you. What is stable today: diagnostic codes, the command envelope shapes, the manifest format identifier, and the artifact-identity model. What may still move: parts of the SDK surface, and anything marked deprecated.

#How do I report a bug or ask for something?

github.com/impetik/xeer. Issues and discussions both work. A --json transcript of the failing command is the most useful thing you can attach — it carries the diagnostic code, the file, and the span.

#Is it open source?

The framework is MIT-licensed: the CLI, the compiler, the SDK, the runtime, the local development server, the test runner, and the MCP server. The hosted platform that xeer deploy talks to is not.

#Why does an agent keep coming up in the docs?

Because it shaped the design. Every command emits structured output, every failure carries a stable code and a suggested repair, and the whole app is described by one declarative file — which makes the framework drivable by a program. It also, not coincidentally, makes it small enough for a person to hold in their head. See Building with AI agents.