# Qyant

> Full public documentation for Qyant, the vibe coding platform at https://qyant.dev. This file is the long form of /llms.txt.

Qyant builds a Next.js app with a frontend, a backend, and a private Postgres database from a description. Each change is a diff you accept or reject. The code can sync one way to a GitHub repository you own, and you can publish it to an HTTPS URL on apps.qyant.dev. The Starter plan is free. Email contact@qyant.dev.

Qyant does not yet offer a custom domain, or built-in sign-in for an app's users.

## Introduction

Source: https://qyant.dev/docs/getting-started/introduction
What Qyant is, what it builds, and how the loop of describe → review → ship works.

Qyant turns a description into a working full-stack application — and keeps you in charge of every change along the way.

You describe what you want in plain language. Qyant plans the change, writes the code, runs it in an isolated sandbox with its own Postgres database, and shows you the result on a live preview URL. Every edit arrives as a **diff you accept or reject**, file by file. When you're happy, you push the code to a GitHub repository you own and deploy to a public HTTPS URL in one click.

## What you get with every project

| | |
|---|---|
| **Stack** | Next.js 16 (App Router), React 19, TypeScript, Tailwind CSS v4, Postgres via `pg` |
| **Runtime** | An isolated container per project, under gVisor kernel isolation |
| **Database** | A private Postgres database with its own credentials, provisioned automatically |
| **Preview** | `preview--<your-app>.apps.qyant.dev`, live-reloading, visible only to you |
| **Deployment** | `<your-app>.apps.qyant.dev` over HTTPS, one click |
| **Models** | Every chat model on OpenRouter — Claude Opus 5, Sonnet 5, GPT-6 Astra, DeepSeek, Qwen, Kimi and 440 more |
| **Ownership** | Your code, in your GitHub, exportable any time |

## How a change flows

1. **You describe.** A sentence or a paragraph — see [Writing prompts](/docs/building/prompts).
2. **The model plans and writes.** It reads your whole project first, then proposes changes. You can watch its reasoning if the model exposes it.
3. **You review.** Each changed file is a diff with **Accept** / **Reject**. Nothing lands until you say so — see [Reviewing changes](/docs/building/reviewing-changes).
4. **The preview updates.** Accepted files are pushed into the running sandbox and the preview reloads.
5. **You ship.** [Sync to GitHub](/docs/preview-and-deploy/github) and [deploy](/docs/preview-and-deploy/deploy).

## Who this is for

- Founders and product people who can describe a product precisely and want a real, deployable codebase — not a prototype locked in a tool.
- Developers who want the speed of generation without giving up review, versioning and a normal Git workflow.
- Teams that need the generated code to run somewhere serious: isolated, with a proper database, behind previews only they can open.

## Where to go next

- New here? Start with the [Quickstart](/docs/getting-started/quickstart) — first app live in about five minutes.
- Want the mental model first? Read [Concepts](/docs/getting-started/concepts).

## Quickstart

Source: https://qyant.dev/docs/getting-started/quickstart
From a sentence to a live preview in about five minutes, then to a public URL.

This walkthrough takes you from nothing to a running app on a public URL. It assumes nothing except a browser.

## 1. Create an account

Go to [qyant.dev](/) and either type your idea into the box on the home page or click **Start building**. Sign up with email and password, Google, or GitHub. If you typed a prompt first, the builder opens with it ready to send.

The free **Starter** plan needs no card and includes 200 credits a month — enough to build and iterate on a first project.

## 2. Create a project

From the dashboard click **Create project**, give it a name, and open it. Every project starts from the same template: a Next.js 16 app with a `items` table already wired to its own Postgres database, so the first preview is a working page, not a blank screen.

The name becomes the project's permanent URL slug (`daily-khata` → `preview--daily-khata.apps.qyant.dev`). Slugs are globally unique; if the name is taken you'll get a short suffix.

## 3. Start the preview

Click **Run preview**. The first start installs dependencies and compiles the app; expect around a minute. The progress bar tells you which step is running — *Prepare → Install → Start → Live*. When it's live, the app appears on the right and a preview URL is available under **Open**.

## 4. Send your first prompt

In the chat on the left, describe the first thing you want. Be concrete:

> Turn this into a simple expense tracker. Add an `expenses` table (amount, category, note, date), a form to add one, and a list grouped by month with monthly totals.

Pick a model and a thinking level from the two dropdowns above the chat if you want to change the defaults (Claude Opus 5, medium). See [Models & thinking](/docs/building/models).

## 5. Review and accept

The response streams in. When it's done, the changed files appear as a review list with a diff for each. Read them, then **Accept all** — or reject individual files. Accepted files are written to the sandbox and the preview reloads within a few seconds.

Your project's version number increments with every accepted change; you can roll back to any earlier version later.

## 6. Iterate

Keep going in the same chat. The model always sees the current state of every file, so "make the totals bold and add a delete button" works without re-explaining the app.

## 7. Push to GitHub and deploy

Open the project menu → **Sync to GitHub**. The first time, you'll authorise Qyant for repositories; it creates a repo under your account and pushes the current version. After that, every sync pushes a commit.

Then click **Deploy**. Qyant builds a production bundle and serves it at `https://<your-app>.apps.qyant.dev`, using the same isolated runtime and the same database as your preview. See [Deploy](/docs/preview-and-deploy/deploy).

## What just happened

- Your app ran in a **kernel-isolated container** with a **private Postgres**, created automatically — see [Isolation](/docs/security/isolation).
- The `.env` you can see in the file tree was generated by Qyant with real values; the model never sees the secrets in it — see [Environment variables](/docs/building/environment-variables).
- Everything you accepted is versioned; everything you pushed is in a repo you own.

## Concepts

Source: https://qyant.dev/docs/getting-started/concepts
Projects, versions, sandboxes, previews, deployments, credits — the vocabulary the rest of the docs use.

A short tour of the nouns. Each links to the page that covers it in depth.

## Project

The unit of everything. A project is a set of files (the app), a chat history, a version history, a private database, and at most one running sandbox and one live deployment. Projects are private to the account that owns them.

## Version

Every accepted change bumps the project's version. Versions are immutable snapshots of all files; you can revert to any of them from the builder. Manual edits you save in the editor also create versions.

## Change set

What the model proposes in response to a prompt: one or more file operations (create, update, delete), each shown as a diff. A change set is *pending* until you act on it. Accepting writes it to the project (and the running sandbox); rejecting discards it. You can accept some files and reject others.

## Sandbox

The isolated container that runs your app's dev server for the preview. One per project, started on demand, stopped automatically after 30 minutes without activity. Sandboxes run under gVisor with dropped capabilities and hard CPU, memory and process limits — see [Isolation](/docs/security/isolation).

## Preview

Your app, as served by the sandbox, at `https://preview--<slug>.apps.qyant.dev`. Only the project owner (signed in) can open it. Hot reload works, so accepted changes appear in a few seconds. See [Live preview](/docs/preview-and-deploy/live-preview).

## Deployment

A production build of a specific version, served publicly at `https://<slug>.apps.qyant.dev`. Deploying again replaces the previous deployment with a brief overlap, never a gap. See [Deploy](/docs/preview-and-deploy/deploy).

## Database

Each project has its own Postgres database and its own role. The connection string is placed in the project's `.env` as `DATABASE_URL`, and the same database serves both preview and deployment. See [Database](/docs/building/database).

## Credits

One credit is one AI request (one prompt you send). Plans include a monthly number of credits and a monthly AI allowance; both reset on the first of the month. See [Plans & credits](/docs/account/plans-and-credits).

## Model and thinking level

Which model answers, and how much it reasons before answering. Both are per-request choices in the builder. See [Models & thinking](/docs/building/models).

## Slug

The URL-safe name derived from your project name, used in preview and deployment hostnames. Slugs are unique across all of Qyant and permanent for the life of the project.

## Writing prompts

Source: https://qyant.dev/docs/building/prompts
How to describe changes so the model gets them right the first time.

The model sees your **entire project** — every file, the chat history, and the template's conventions — before it writes anything. You don't need to paste code or explain the stack. What it needs from you is intent, scope and any decisions you care about.

## The shape of a good prompt

**Say what, for whom, and what "done" looks like.**

> Add a customers page for our sales team: a searchable table (name, company, owner, status), a "New customer" form, and a detail page per customer showing their call log. Search should filter on the server.

That prompt gives the model the feature, the audience, the fields, and one implementation constraint. It will pick the schema, routes and components itself.

## What works well

- **One feature per prompt.** "Add auth" and "add billing" are two prompts. Smaller change sets are easier to review and cheaper to redo.
- **Name the data.** Listing the fields you care about ("amount, category, note, date") prevents guesses you'll have to fix.
- **State constraints, not implementations.** "Filter on the server", "must work on mobile", "no external UI library" — the model handles the how.
- **Reference what exists.** "Use the same card style as the dashboard" or "extend `lib/items.ts`" — it knows those files.
- **Attach a screenshot** when layout matters. See [Attachments](/docs/building/attachments).

## What to avoid

- **Vague adjectives alone.** "Make it better" produces arbitrary changes. "Make the table denser and add sorting on every column" does not.
- **Contradicting the stack.** The project is Next.js App Router with Postgres; asking for a different framework won't be honoured.
- **Secrets in prompts.** Put API keys in `.env` (see [Environment variables](/docs/building/environment-variables)), never in chat.

## Iterating

Follow-ups are cheap because context is preserved. Prefer a sequence of focused prompts:

1. "Add the expenses table and a form to add one."
2. "Now list expenses grouped by month with totals."
3. "Add a delete button with a confirmation."

If a change went in a direction you don't like, **reject** it and re-prompt with what was wrong, rather than layering fixes on top.

## Long tasks

Big prompts are fine. Qyant streams the whole response, keeps going when the model reaches its output limit (it asks the model to continue from exactly where it stopped, up to four times), and never cuts a healthy generation short on a timer. A long multi-file change can take several minutes; the progress stays visible the whole time.

## Cancelling

Click **Stop** while a response is streaming. Whatever was produced so far is kept in the chat, marked as interrupted, and nothing is written to the project.

## Prompt length

Prompts can be up to 20,000 characters. Pasting a spec or a page of requirements is a good use of that.

## Reviewing changes

Source: https://qyant.dev/docs/building/reviewing-changes
Accept, reject, diffs, versions and rollback — nothing lands in your project without you.

Qyant never writes to your project on its own. Everything the model produces is a **proposal**; this page is about how you act on it.

## The review panel

When a response finishes, its file changes appear as a list: created files, updated files and deletions, each with a coloured marker in the file tree. Click any file to see the diff — added lines, removed lines, with the surrounding context.

You have three choices per change set:

- **Accept all** — every file is written, the project's version increments, the sandbox receives the files and the preview reloads.
- **Reject** — the whole proposal is discarded. The chat keeps the model's message so you can refer to it in your next prompt.
- **Per-file** — accept some files and reject others from the diff view. Accepted files become one version; rejected ones are dropped.

Until you choose, the proposal stays pending and the preview keeps running the last accepted version.

## Versions

Every accepted change set — and every manual save in the editor — creates a new version: a full, immutable snapshot of the project's files. The version number is shown in the project header (`v13`) and in each review card (`v12 → v13`).

## Rolling back

Open the project's version history and choose **Revert** on any earlier version. Reverting creates a *new* version whose contents match the old one, so history is never rewritten and you can always come forward again. The sandbox is synced and the preview reloads immediately.

## Reviewing well

- **Read the deletions first.** Removed lines are where surprises hide.
- **Check `lib/db.ts` and schema changes carefully.** Database changes are the hardest to undo once real data is in.
- **Reject early.** If the direction is wrong, reject and re-prompt; don't accept and then ask for a fix on top.
- **Trust but verify the preview.** Accepting reloads the preview in a few seconds — click through the feature before the next prompt.

## What happens to `.env`

The model can read the variable *names* in your `.env` but never the values of managed secrets (`DATABASE_URL` is shown to it as `<managed-by-qyant>`). When you accept a change that touches `.env`, Qyant restores the real values before writing. See [Environment variables](/docs/building/environment-variables).

## Models & thinking

Source: https://qyant.dev/docs/building/models
Choosing between 446 models, the recommended shortlist, and what the thinking level does.

Qyant routes every request through OpenRouter, which means every chat-capable model they list is available from the picker in the builder — 446 at the time of writing, from Anthropic, OpenAI, Google, xAI, DeepSeek, Meta, Mistral, Qwen, Moonshot and others.

## The picker

The model dropdown sits above the chat. Search by name, id or vendor. Each row shows the context window, the price per million tokens (input / output), and two badges: **thinking** (the model exposes reasoning) and **images** (it accepts attachments).

Your choice is remembered per browser. New accounts start on **Claude Opus 5**.

## Recommended

The shortlist at the top is curated for building software:

| Model | Reach for it when |
|---|---|
| **Claude Opus 5** | A feature has to be right the first time. Strongest at holding a large codebase in view and reasoning through refactors. The default. |
| **Claude Sonnet 5** | Everyday iteration — fast enough to keep a rhythm, strong enough to carry most work. |
| **GPT-6 Astra** | Very large projects; questions that span many files. |
| **DeepSeek V4.1 Flash** | Stretching credits — small edits, copy tweaks, cleanup. |
| **Qwen3.8 Max** | Precise, instruction-heavy coding tasks at a low price. |
| **Kimi K3** | Multi-step features from a single prompt; plans well and sticks to the plan. |
| **Auto** | Let the router pick per request based on the prompt. |

Everything else is under its vendor further down — older Claude versions, GPT-5 family, Gemini, Llama, Mistral and so on.

## Thinking level

The **Think** dropdown sets how much the model reasons before answering: **none**, **low**, **medium** (default) or **high**. Higher levels produce better results on hard tasks — schema design, tricky refactors, debugging — at the cost of time and credits. For copy changes or small UI tweaks, low or none is plenty.

When the model exposes its reasoning, it streams into a collapsible **Thought process** card above the answer, so you can see *why* it made a choice.

## Cost

Each request costs what the provider charges for the tokens used, counted against your plan's monthly AI allowance; one request is one credit regardless of model. Prices in the picker are per million tokens. A typical feature-sized request on a frontier model is a few cents; on the budget models it's a fraction of that.

## Vision

Models with the **images** badge accept screenshots and mockups as [attachments](/docs/building/attachments). If you attach an image to a model without vision support, the request is refused before it's sent.

## Attachments

Source: https://qyant.dev/docs/building/attachments
Sending screenshots and mockups with a prompt.

A picture is often the fastest way to describe a layout, a bug or a design you want to match. You can attach images to any prompt.

## How to attach

Any of these, in the chat box:

- Click the **image** button and choose files.
- **Drag and drop** images onto the chat.
- **Paste** a screenshot from the clipboard.

Thumbnails appear under the prompt; remove one with its ×.

## Limits

- Up to **4 images** per prompt.
- Up to **5 MB** each.
- PNG, JPEG, WebP and GIF.

## What the model does with them

The images are sent alongside your text to the model you've selected. Use the prompt to say what the image is for:

> Match this layout for the dashboard header. Keep our colours.

> This is what the table looks like after adding a row — the total is wrong. Find the bug.

Attachments are stored with the message and shown in the chat history, so they remain part of the project's context for later prompts.

## Model support

Only models with the **images** badge in the picker accept attachments. The recommended models all do. If you attach an image and choose a text-only model, Qyant tells you before sending.

## Environment variables

Source: https://qyant.dev/docs/building/environment-variables
How .env works: the values Qyant manages, the ones you add, and what the model can and cannot see.

Every project has a `.env` file at its root. Qyant generates it, keeps parts of it up to date, and keeps its secrets out of the model's view.

## What Qyant manages

Two variables are written and refreshed by Qyant whenever the preview starts:

| Variable | Value |
|---|---|
| `DATABASE_URL` | The connection string for the project's private Postgres database |
| `PORT` | The port the dev server listens on inside the sandbox |

Don't edit these; they're overwritten on the next start. The header comment in the file says the same.

## What you add

Everything else is yours. Add API keys and configuration the normal way:

```env
STRIPE_SECRET_KEY=sk_live_…
NEXT_PUBLIC_APP_NAME=Acme CRM
```

Save the file (the editor's **Save** button) and restart the preview for the running app to pick the new values up. Variables prefixed `NEXT_PUBLIC_` are exposed to the browser, as in any Next.js app; everything else is server-only.

## What the model sees

The model needs to know **which variables exist** to write correct code, but it must never see secret **values**. So:

- Variable *names* are visible to the model.
- The values of managed secrets (`DATABASE_URL`) are shown to it as `<managed-by-qyant>`.
- When the model proposes a change to `.env` (adding a new variable, say), the real values are restored before the file is written on accept.

The model can — and often will — add variables it needs. For example, if you ask for email sending it may add `RESEND_API_KEY=` to `.env` and tell you to fill it in.

## GitHub and deployments

`.env` is **never pushed to GitHub** and **never baked into a deployment image**. Deployments receive their configuration as container environment variables at start: `DATABASE_URL` is injected automatically; variables you added in `.env` are carried over from the project so the deployed app behaves like the preview. Rotate a secret by editing `.env` and redeploying.

## Reading variables in code

Standard Next.js:

```ts
// server code only
const key = process.env.STRIPE_SECRET_KEY;

// available in the browser too
const name = process.env.NEXT_PUBLIC_APP_NAME;
```

## Related

- [Database](/docs/building/database) — what `DATABASE_URL` points at.
- [Data & privacy](/docs/security/data-and-privacy) — how secrets are handled across the platform.

## Database

Source: https://qyant.dev/docs/building/database
Every project's private Postgres: how it's provisioned, how to use it, and how to look inside.

Every project gets its own Postgres database with its own role and password, created the first time the preview starts. No setup, no shared tables, no way for one project to read another's data.

## What you get

- A dedicated database on a Postgres 16 cluster reserved for project databases (separate from Qyant's own).
- A role that can only access that database.
- `DATABASE_URL` in your `.env`, pointing at it. The **same database** is used by the preview and by deployments, so data you enter while building is there in production.

## The template's wiring

The starter project already talks to the database:

- `lib/db.ts` — a `pg` connection pool built from `DATABASE_URL`, with a `query<T>(text, params)` helper.
- `lib/items.ts` — creates an `items` table on first use and exposes `listItems` / `addItem`.
- `app/api/items/route.ts` — a route handler the home page's form posts to.

Ask the model for tables and it will follow the same pattern: SQL through the pool, tables created if missing, server-side code only.

## Working with schema

The template uses plain SQL rather than an ORM, which keeps generated code readable and reviewable. Typical prompts:

> Add a `calls` table (customer_id → customers, notes, called_at) and a function to list calls for a customer.

> We're storing money as floats — change amounts to integer cents everywhere.

Review schema changes carefully before accepting; see [Reviewing changes](/docs/building/reviewing-changes). Adding an ORM (Prisma, Drizzle) is possible — ask for it — but it adds a migration step to every schema change.

## Connecting from outside

The connection string in `.env` is reachable only from inside Qyant's network. There is no public database endpoint today. To inspect data, ask the model for an admin page or an export endpoint, or query through a route handler.

## Backups and lifetime

Project databases live as long as the project. Deleting a project drops its database. Qyant's nightly infrastructure backups cover project databases, but they're a disaster-recovery measure, not a point-in-time restore you can trigger — export anything you can't lose.

## Limits

There are no per-row or per-table quotas. Storage is subject to fair use on all plans; if you're building something data-heavy, [talk to us](/contact).

## Editing files

Source: https://qyant.dev/docs/building/editing-files
The built-in editor, manual saves, and how they fit with AI changes.

The model does most of the writing, but you can open and edit any file yourself.

## The file tree

The middle pane lists every file in the project. Folders first, then files. A **blue dot** marks a file with a pending AI change; created files show a plus icon, deletions a cross. Click a file to open it in the editor.

## The editor

A full code editor with syntax highlighting for TypeScript, TSX, CSS, JSON, Markdown and shell, bracket matching and multiple cursors. Colourful file-type icons and a choice of editor themes are in **Settings → Editor**.

Edit, then click **Save**. A save:

1. writes the file to the project as a new version,
2. pushes it into the running sandbox,
3. reloads the preview.

Unsaved edits are kept while you switch between files, but they're lost if you leave the builder — save before navigating away.

## Editing with a pending AI change

If you open a file that has a pending change, you see the **diff**, not the editor. Accept or reject the change first, then edit. This keeps "what the model proposed" and "what you typed" from getting tangled.

## Creating and deleting files

Ask the model ("create `lib/format.ts` with a currency formatter") — it's faster and it wires imports for you. Deleting is the same: "remove the old `components/legacy-form.tsx` and its usages".

## `.env` and generated files

`.env` is editable but two lines are managed by Qyant — see [Environment variables](/docs/building/environment-variables). `node_modules`, `.next` and other build output are never part of the project and never appear in the tree.

## Limits

Up to 2,000 files per project, 1 MB per file. Binary assets (images, fonts) are better served from a URL or a storage bucket than committed to the project.

## Live preview

Source: https://qyant.dev/docs/preview-and-deploy/live-preview
Your app running on its own URL while you build — how it starts, updates, and stops.

The preview is your app, running for real in an isolated sandbox, on a URL only you can open.

## Starting

Click **Run preview** (or send a prompt — the preview starts automatically the first time). The first start:

1. **Prepare** — provisions the database if needed and writes `.env`.
2. **Install** — installs dependencies. The template's dependencies are pre-installed in the sandbox image, so this is fast unless you've added packages.
3. **Start** — launches the Next.js dev server.
4. **Live** — the first page has compiled and answered.

Typically under a minute; the progress panel shows the current step and how long it has taken. If a step fails, the panel shows why and offers **Try again**.

## The URL

`https://preview--<slug>.apps.qyant.dev` — shown in the preview header and under **Open** (opens in a new tab). The preview is **private**: it answers only to the signed-in project owner. Anyone else gets a sign-in prompt. This is deliberate; to share a running app, [deploy it](/docs/preview-and-deploy/deploy).

## Updating

- **Accepting a change** or **saving a file** pushes the files into the sandbox; Next's hot reload picks them up in a few seconds.
- Changing `.env` or `package.json` needs a **restart** (Stop → Run preview) so the process sees the new values or installs the new package.

## Errors in your app

Because the preview runs the real dev server, runtime errors show Next.js's error overlay with the stack trace — the same thing you'd see locally. Paste the message into the chat and ask for the fix.

## Stopping

Previews stop automatically after **30 minutes without activity** to free resources, and you can stop one any time with **Stop preview**. Starting again is faster than the first time. Your files and database are unaffected by stops.

## Resources

Each sandbox has 1 vCPU, 2 GB of memory and a process limit. That's comfortable for a Next.js dev server; if you're doing something unusual (video processing, large in-memory datasets) it's the first thing to check when something is slow.

## Concurrency

The number of previews you can have running at once depends on your plan — see [Limits](/docs/account/limits).

## Deploy

Source: https://qyant.dev/docs/preview-and-deploy/deploy
Publishing a version of your app to a public HTTPS URL.

Deploying builds a production bundle of the current version and serves it at a public URL. It takes one click.

## What happens

1. Qyant snapshots the current version's files.
2. A fresh container installs dependencies, runs `next build`, and starts the production server.
3. When the app answers, traffic is switched to the new container. The previous deployment is retired a moment later — a brief overlap, never a gap.
4. The deployment is live at `https://<slug>.apps.qyant.dev`.

Progress streams into the builder; a failed build shows its log so you can fix and redeploy.

## Configuration

Deployments receive `DATABASE_URL` for the project's database automatically, plus the variables from your `.env`. `.env` itself is never copied into the image. See [Environment variables](/docs/building/environment-variables).

## Same isolation as the preview

A deployment runs in the same kind of sandboxed container as the preview — kernel-isolated, capability-dropped, resource-limited — and against the same private database. See [Isolation](/docs/security/isolation).

## Redeploying and rolling back

Deploy again at any time to publish the current version. To roll back, [revert to an earlier version](/docs/building/reviewing-changes#rolling-back) in the builder and deploy.

## Custom domains

Deployments currently live on `apps.qyant.dev`. Bringing your own domain is not available yet; if you need it, [tell us](/contact) — it helps us prioritise.

## Limits

The number of live deployments per account depends on your plan — see [Limits](/docs/account/limits). One deployment per project is live at a time.

## GitHub sync

Source: https://qyant.dev/docs/preview-and-deploy/github
Pushing your project to a repository you own.

Your code belongs to you. GitHub sync puts it in a repository under your GitHub account, where you can clone it, review history, open pull requests or take it anywhere else.

## Connecting

The first time you sync, Qyant asks you to authorise it with GitHub for repository access. You can revoke that at any time from GitHub's application settings; syncing will simply stop working until you authorise again.

If you signed up with GitHub, the connection is already there.

## Syncing

Project menu → **Sync to GitHub**. On first sync Qyant creates a repository (private by default) named after the project and pushes the current version to `main`. Later syncs push a new commit with the changes since the last one.

The project header shows the linked repository. The repository name and default branch are visible on the project card.

## What is pushed

Every project file except `.env`. Secrets never leave Qyant this way. A `.gitignore` is part of the template so `node_modules` and build output stay out too.

## What is not synced back

Sync is one-way: Qyant → GitHub. Commits you make in the repository are not pulled into the project. If you want to keep working in Qyant after editing elsewhere, bring the change back through a prompt or the editor.

## Running the project elsewhere

The repository is a standard Next.js app:

```bash
git clone git@github.com:you/your-app.git
cd your-app
cp .env.example .env   # set DATABASE_URL to a Postgres you own
npm install
npm run dev
```

Nothing in the generated code depends on Qyant.

## Plans & credits

Source: https://qyant.dev/docs/account/plans-and-credits
What each plan includes, what a credit is, and when things reset.

## Plans

| | Starter | Qyant Lite | Pro | Pro Plus |
|---|---|---|---|---|
| Price | Free | $10 / mo | $25 / mo | $40 / mo |
| Billed annually | — | $8 / mo | $20 / mo | $32 / mo |
| Credits / month | 200 | 500 | 1,200 | 2,000 |
| Projects | 3 | 25 | 50 | Unlimited |
| Concurrent previews | 5 | 10 | 15 | 20 |
| Live deployments | 1 | 10 | 20 | 30 |

An **Enterprise** plan with custom limits, invoicing and support is available — [contact us](/contact).

## Credits

One credit is one AI request: one prompt you send, regardless of the model or how long the answer is. Credits reset on the first of each month and don't roll over.

Alongside credits, each plan includes a monthly **AI allowance** that covers the provider cost of your requests. Heavier models and higher thinking levels use it faster; the budget models barely touch it. Your current usage of both is on the [Billing](/billing) page and in the account menu.

## When you run out

When either the credit count or the allowance for the month is used up, new requests are declined with a clear message until the next reset — or immediately if you upgrade. Previews, deployments and editing keep working; only new AI requests pause.

## Starter

The free plan is a real plan, not a trial: it never expires and needs no card. It's sized for building and iterating on a small project.

## Changing plans

Upgrade or downgrade any time from [Billing](/billing). Upgrades apply immediately with prorated billing; downgrades apply at the end of the current period. See [Billing](/docs/account/billing).

## Usage

Source: https://qyant.dev/docs/account/usage
Seeing what you've used, per month and per request.

## Where to look

- **Account menu** (top right, anywhere in the app) — credits left this month with a progress bar.
- **Billing page** — credits used, AI allowance used, projects, running previews and deployments against your plan's limits, and lifetime AI spend.
- **Dashboard** — the same headline numbers next to your recent projects.

Usage updates in real time as requests complete.

## How a request is counted

Each request records the model, the tokens in and out, and the provider's actual cost for that generation. The cost is fetched from the provider after the request; when it isn't available immediately it's reconciled within a few minutes, so a number may briefly show as pending.

A request that you cancel mid-way, or that fails, still counts the tokens that were produced.

## Resets

Credits and the AI allowance reset at 00:00 UTC on the first of the month.

## Billing

Source: https://qyant.dev/docs/account/billing
Payments, invoices, plan changes and cancellation.

Paid plans are billed through **Paddle**, our merchant of record. Paddle handles cards, local payment methods, VAT/sales tax and invoices, and holds your payment details — Qyant never sees your card number.

## Subscribing

Choose a plan on [Pricing](/pricing) or [Billing](/billing). Checkout opens in an overlay; you can pay monthly or annually. Your plan updates within a few seconds of payment.

## Managing your subscription

**Billing → Manage subscription** opens the Paddle customer portal where you can update your payment method, download invoices, and see upcoming charges.

## Changing plans

**Billing → Change plan.** Upgrades take effect immediately and are prorated; downgrades take effect at the end of the current billing period.

## Cancelling

From the customer portal. Your plan stays active until the end of the paid period, then drops to Starter. Projects, files and databases are kept; anything above Starter's limits stays as it is but you can't add more until you're back within limits.

## Invoices and tax

Invoices come from Paddle, with your VAT ID if you've added one in the portal. Prices shown are exclusive of tax where tax applies.

## Failed payments

If a renewal fails, Paddle retries and emails you. The plan continues during the retry window; if payment isn't recovered it drops to Starter.

## Limits

Source: https://qyant.dev/docs/account/limits
Every hard limit in one place.

## Per plan

| | Starter | Lite | Pro | Pro Plus |
|---|---|---|---|---|
| Credits / month | 200 | 500 | 1,200 | 2,000 |
| Projects | 3 | 25 | 50 | Unlimited |
| Concurrent previews | 5 | 10 | 15 | 20 |
| Live deployments | 1 | 10 | 20 | 30 |

## Per project

| | |
|---|---|
| Files | 2,000 |
| File size | 1 MB |
| Running previews | 1 |
| Live deployments | 1 |

## Per request

| | |
|---|---|
| Prompt length | 20,000 characters |
| Attachments | 4 images, 5 MB each |
| Continuations | up to 4 when the model hits its output limit |

## Sandbox

| | |
|---|---|
| CPU | 1 vCPU |
| Memory | 2 GB |
| Processes | 256 |
| Idle stop | 30 minutes without activity |
| Startup budget | 7 minutes before a start is marked failed |

## Rate limits

Unusual bursts of requests from one account are throttled to protect the service. Normal interactive use never hits them. If you're building automation on top of Qyant, [talk to us](/contact).

## Isolation

Source: https://qyant.dev/docs/security/isolation
How generated code is kept away from everything else — including other customers.

Generated code is untrusted code. Qyant is built on that assumption.

## Every project in its own container

Each preview and each deployment runs in its own container. Containers are created with:

- **gVisor** (`runsc`) as the runtime — a user-space kernel that sits between the container and the host kernel, so a kernel exploit inside your app doesn't reach the machine.
- **All Linux capabilities dropped** and privilege escalation disabled.
- **Hard limits** on CPU, memory and number of processes.
- A **non-root user** inside the container.
- **Read-only** system files; writable space is a size-capped scratch area.

## Network

Containers reach the internet (to install packages and call the APIs you use) but not Qyant's own control plane, and not each other's ports. The database host is pinned by address; there is no service discovery to enumerate.

## Database

Each project has a dedicated Postgres database and role on a cluster used **only** for project databases. The role cannot see other databases. Qyant's own data lives on a different cluster entirely.

## Previews

A preview URL answers only to the signed-in owner of that project; every request is checked against the session and the project. The preview proxy strips cookies the app might set so nothing can collide with your Qyant session, and prevents the app from being embedded anywhere except the Qyant builder.

## Thumbnails

The screenshots on your project cards are taken by a headless browser that renders your app with its own sandbox enabled and can only load resources from the app itself and public asset hosts — never from Qyant's internal network.

## What we don't claim

Qyant is not currently SOC 2 or ISO 27001 certified. If a certification is a requirement for you, [tell us](/contact); it shapes our roadmap.

## Data & privacy

Source: https://qyant.dev/docs/security/data-and-privacy
Where your code, data and secrets go — and where they don't.

## Your code

- Stored in Qyant's database, versioned, private to your account.
- Pushed only to a GitHub repository **you** own, and only when you click Sync.
- Exportable at any time via that repository.

## Your secrets

- `.env` values you add are stored with the project and injected into your app at runtime.
- Managed secrets are **never shown to the model** — it sees `<managed-by-qyant>` in place of values.
- `.env` is never pushed to GitHub and never included in a deployment image.
- Credentials Qyant holds on your behalf (GitHub tokens, database passwords) are encrypted at rest.

## Prompts and model providers

Your prompts, the relevant project files and any attachments are sent to the model you selected, via OpenRouter. What each provider does with request data is governed by that provider's terms; the picker shows you which vendor you're sending to on every request. We do not train models on your data.

## Your app's data

Whatever your app stores in its database is yours. Qyant staff do not read project databases except when you ask us to help with a specific problem.

## Sessions

Signing in sets a single httpOnly cookie scoped to `qyant.dev`. There are no tokens to leak into local storage or URLs. Sessions expire after a period of inactivity and can be ended from Settings.

## Deleting a project

Deleting a project removes its files, versions, chat history, attachments, sandbox and **its database**. This is immediate and cannot be undone. The GitHub repository, if any, is untouched.

## Deleting your account

Contact [contact@qyant.dev](mailto:contact@qyant.dev) from your account's email address. All projects and their databases are deleted; billing is cancelled.

## Status page

Source: https://qyant.dev/docs/security/status
Live platform status, uptime history and incidents at qyant.dev/status.

[qyant.dev/status](/status) shows the live state of every part of the platform, with 90 days of history.

## What it measures

Every minute, from production, Qyant probes:

| Component | Check |
|---|---|
| API | Responsiveness of the API process |
| Database | A query against the primary database |
| Realtime & queues | The message bus behind live streaming and background jobs |
| Sandboxes | The container runtime |
| Preview URLs | An HTTPS request through the edge to a preview hostname |
| Deployed apps | An HTTPS request through the edge to a deployment hostname |
| AI generation | Reachability of the model gateway |
| Email delivery | The outbound mail connection |

Each check is recorded. The page derives everything from those records — current status, 90-day uptime bars, 24-hour response time and incidents. Nothing is set by hand.

## Reading it

- **Operational** — the last check passed within its normal response budget.
- **Degraded** — the check passed but was slower than its budget.
- **Outage** — the check failed.

Incidents are two or more consecutive failed minutes on a component, with start, end and duration.

## If the page is green but something's wrong for you

Tell us — [contact support](/contact). Component checks can't see every kind of problem, and a report from you is exactly what catches the rest.

## Preview won't start

Source: https://qyant.dev/docs/troubleshooting/preview-not-starting
Working through a preview that stays on Installing, fails to start, or shows an error.

The progress panel names the step that's stuck. Find it below.

## Stuck on "Installing dependencies"

The template's packages are pre-installed, so a long install means **you've added packages** (or the model did). A large dependency can take a couple of minutes on the first start. If it exceeds the startup budget, the panel shows the install log — look for the failing package.

Common causes:
- A package that needs native build tools (`sharp`, `bcrypt`, `canvas`) — ask the model for a pure-JS alternative (`bcryptjs`, `jimp`).
- A typo in `package.json` from a manual edit — check the JSON is valid.

## "The app exited during startup"

The dev server crashed immediately. The panel shows the last lines of the log. Typical:

- **`Module not found`** — a file imports something that doesn't exist. Paste the error into the chat; the model will fix the import or create the file.
- **A syntax error** in a file you edited by hand — open it in the editor.
- **Port already in use** inside the container — Stop and Run again.

## "Did not respond within 7 minutes"

The process is running but the first page never answered. Usually the first compile is hung on a bad file. Open the preview URL in a new tab: if Next shows an error overlay, that's the file. Otherwise Stop, Run again, and if it repeats, revert to the last version that worked.

## Preview loads but shows an error page

That's your app's own error — the Next.js overlay shows the stack trace. The most common one on a fresh project is a database query failing because a table doesn't exist yet; the template creates tables on first use, but code the model wrote may not. Ask it to add the `CREATE TABLE IF NOT EXISTS` for the new table.

## Preview loads but is blank

Check the browser console (F12 → Console). A client-side exception in a component leaves the page empty. Paste the message into the chat.

## "Sign in to view this preview"

You're opening the preview from a browser or profile where you're not signed in to Qyant, or as a different user. Previews are owner-only. Sign in in that browser, or [deploy](/docs/preview-and-deploy/deploy) to share.

## Still stuck

**Stop preview → Run preview** restarts the whole container. If a restart doesn't help and the last change is suspect, revert to the previous version. If neither works, [contact support](/contact) with the project name and the text from the progress panel.

## Generation interrupted

Source: https://qyant.dev/docs/troubleshooting/generation-interrupted
What the different interruption messages mean and what to do.

When a response can't complete, the chat keeps whatever was produced and marks it *(generation interrupted: …)*. Nothing is written to your project. Here is what the reasons mean.

## "The model stopped responding: no data for 90s mid-stream"

The provider stopped sending tokens for a minute and a half. This is a provider-side stall, not a limit on your side. Send the prompt again — often a different provider route is used. If it repeats on one model, try another from the picker.

## "The model stopped responding: no response for 180s after the request was sent"

The provider accepted the request but never started answering. Same remedy: retry, or switch model. The status page shows whether the model gateway is having a wider problem.

## "Generation cancelled"

You clicked Stop.

## The answer ended mid-file

This should be rare: when a model reaches its output limit, Qyant asks it to continue from exactly where it stopped, up to four times, and stitches the result. If a change set still arrives incomplete, the review will show the truncated file — reject it and re-prompt with a smaller scope ("just the API route first").

## "Monthly credit limit reached" / "AI allowance used up"

You've used this month's credits or allowance. See [Plans & credits](/docs/account/plans-and-credits); upgrading lifts the limit immediately.

## Timeouts are never about length

A healthy generation is never cut off for taking long — long multi-file changes can run for many minutes. Only silence from the provider ends a request early.

## Common errors

Source: https://qyant.dev/docs/troubleshooting/common-errors
Short answers to the messages people hit most.

## In the builder

**"This sandbox is not running. Start it from the builder."**
The preview URL was opened while the sandbox is stopped (idle stop after 30 minutes, or you stopped it). Click Run preview.

**"Preview not found."**
The URL doesn't belong to a project on this account. Check you're signed in as the right user.

**"The sandbox stopped responding. Try restarting it."**
The dev server inside the container died or hung. Stop → Run preview.

**A file shows a diff instead of the editor.**
It has a pending AI change. Accept or reject it first — see [Editing files](/docs/building/editing-files).

**Attachment refused.**
Over 4 images, over 5 MB, an unsupported type, or a model without image support. See [Attachments](/docs/building/attachments).

## In your app

**`getaddrinfo` / `ECONNREFUSED` on the database**
`DATABASE_URL` was edited by hand. Restart the preview; Qyant rewrites the managed values.

**`relation "…" does not exist`**
A table the code expects hasn't been created. Ask the model to add table creation for it, following `lib/items.ts`.

**Environment variable is `undefined`**
Added to `.env` but the preview wasn't restarted; or the variable is used in browser code without the `NEXT_PUBLIC_` prefix.

**Hydration mismatch warnings**
Usually a date or random value rendered on the server and again on the client. Ask the model to move it into an effect or format it consistently.

## Account

**"Sign-in link expired"**
Codes are single-use and short-lived. Request a new one.

**Google / GitHub sign-in returns an error**
The provider declined the authorisation, or you have an existing account with that email under a different method. Sign in with the original method, then link the provider from Settings.

**Can't upgrade / checkout doesn't open**
An ad-blocker is likely blocking the payment overlay. Allow `paddle.com` for qyant.dev, or try another browser.

## Something else

[Contact support](/contact) with the project name, what you did, and the exact message. Screenshots help.

## Supported stack

Source: https://qyant.dev/docs/reference/stack
What's in a Qyant project and the versions behind it.

Every project is a standard Next.js application. There is nothing proprietary in the generated code.

## Versions

| | |
|---|---|
| Next.js | 16 (App Router, Turbopack in development) |
| React | 19 |
| TypeScript | 5 |
| Tailwind CSS | 4 |
| Node.js (sandbox) | 22 |
| Postgres | 16 |
| Database client | `pg` |

## Conventions the model follows

- **App Router** with server components by default; client components only where interaction needs them.
- **Route handlers** under `app/api/*` for JSON endpoints; server actions are used where a form posts to the same page.
- **Plain SQL** through the `pg` pool in `lib/db.ts`, tables created if missing.
- **Tailwind utility classes**, no CSS-in-JS.
- **Environment variables** read from `process.env`, server-side unless prefixed `NEXT_PUBLIC_`.

## Adding libraries

Ask for them. The model adds the dependency to `package.json` and uses it; the preview installs it on the next start. Anything on npm that runs on Node 22 without native compilation works out of the box. Native modules can work but may need alternatives — see [Preview won't start](/docs/troubleshooting/preview-not-starting).

## Frameworks other than Next.js

Not today. Every project starts from the Next.js template; the model is told to stay within it. If you need something else, [tell us](/contact).

## Running the code yourself

The repository from [GitHub sync](/docs/preview-and-deploy/github) runs anywhere Node 22 and Postgres are available: your laptop, Vercel, a VPS. Set `DATABASE_URL` and go.

## Project template

Source: https://qyant.dev/docs/reference/project-template
Every file in a new project and what it's for.

A new project contains these files. The model knows them and builds on them.

```
app/
  layout.tsx            Root layout: fonts, metadata, global styles
  page.tsx              Home page — lists items from the database
  globals.css           Tailwind v4 entry
  api/
    items/route.ts      GET lists items, POST adds one
components/
  add-item-form.tsx     Client component posting to /api/items
lib/
  db.ts                 pg pool from DATABASE_URL + query<T>() helper
  items.ts              listItems / addItem; creates the table on first use
.env                    Managed by Qyant — DATABASE_URL, PORT; add your own below
.env.example            The variable names, for running elsewhere
.gitignore              node_modules, .next, .env
next.config.ts
package.json            next 16, react 19, pg, tailwindcss 4, typescript
postcss.config.mjs
tsconfig.json
README.md
```

## `lib/db.ts`

```ts
import { Pool } from "pg";

const pool = new Pool({ connectionString: process.env.DATABASE_URL });

export async function query<T>(text: string, params: unknown[] = []): Promise<T[]> {
  const result = await pool.query(text, params);
  return result.rows as T[];
}
```

Every database access in generated code goes through this helper. It's deliberately small so it's easy to review and easy to swap for an ORM if you want one.

## `lib/items.ts`

Creates `items (id serial, name text, created_at timestamptz)` if it doesn't exist and exposes `listItems()` and `addItem(name)`. New tables the model adds follow the same shape: a module in `lib/` that owns one table.

## Scripts

| | |
|---|---|
| `npm run dev` | What the preview runs |
| `npm run build` | What a deployment runs first |
| `npm start` | What a deployment serves with |

## Glossary

Source: https://qyant.dev/docs/reference/glossary
Terms used across Qyant and these docs.

**Accept / Reject** — Your decision on a proposed change. Accept writes it; reject discards it. Per file or for the whole change set.

**Allowance** — The monthly provider-cost budget included with a plan, alongside credits.

**Auto** — The picker option that lets the router choose a model per request.

**Change set** — The set of file operations the model proposes in one response.

**Credit** — One AI request. Plans include a monthly number.

**Deployment** — A production build of a version, served publicly at `<slug>.apps.qyant.dev`.

**gVisor** — The user-space kernel every sandbox runs under; see [Isolation](/docs/security/isolation).

**Managed variable** — An `.env` entry Qyant writes and refreshes (`DATABASE_URL`, `PORT`).

**OpenRouter** — The gateway through which every model request is routed.

**Preview** — Your app served from the sandbox at `preview--<slug>.apps.qyant.dev`, owner-only.

**Project** — Files, chat, versions, database, sandbox and deployment for one app.

**Reasoning / thinking** — The model's visible working before its answer; the thinking level controls how much.

**Sandbox** — The isolated container that runs a preview.

**Slug** — The URL-safe project name used in hostnames; unique and permanent.

**Sync** — Pushing the project to your GitHub repository.

**Version** — An immutable snapshot of all files, created on every accepted change or manual save.