Documentation
Get started with code-anything
Two ways in: describe an app from scratch, or connect a repo and ship reviewed changes. This page walks both paths step by step, defines every term the product uses, and covers what to do when something goes wrong.
Start here
What this documentation covers
Everything on this page describes the product as it actually behaves: the tabs you will see, the words it uses for things, and the order operations happen in. Read the quickstart that matches your situation, then use the reference sections below it as you hit them.
The create path: you do not have code yet
You describe an application in plain English and get a real, running one back. The agent plans it, writes it, provisions the services it needs, and runs it in a sandbox you can open and click through. You refine it conversationally and visually, then publish it to a public URL. Nothing is installed on your machine and there is no configuration to do first.
Choose this if you are validating an idea, building an internal tool, or replacing a spreadsheet — and you would rather describe the outcome than assemble the parts.
Go to the quickstartThe edit path: you already have a repository
You connect a GitHub repository and describe a change. The agent indexes the codebase, works inside an isolated clone, runs your typecheck, tests and build against its own work, and opens a pull request. Your repository only ever changes when you merge that PR — the agent never pushes to your branches.
Choose this when the code already exists and the thing you actually want is a reviewable diff that has already cleared the checks.
Go to the quickstartBoth paths share the same foundation
Whichever route you take, the machinery underneath is identical: an isolated sandbox the work happens in, a managed backend that is provisioned only when your app needs it, verification that runs before a result reaches you, and monitoring that keeps going after you ship. That is why the reference sections on this page apply to both. The platform overview walks the same ground at a higher altitude.
Quickstart · create path
Prompt to a live website, step by step
Go from a sentence to a published app. A managed Postgres database, authentication, transactional email and payments are provisioned when your app needs them, so you are not wiring infrastructure before you can ship something real.
Create an account
Signing in puts you on the dashboard, which is both the project list and the starting point for a new build. No credit card is needed to start.
What you see: The dashboard, with a single prompt box at the top and a template gallery below it.
Describe the app — or start from a template
Type what you want in plain language: the screens, the data, who uses it and what they do. The more precise the description, the fewer edits you pay for later. If you would rather not start from a blank page, pick something from the template gallery first and describe your changes on top of it.
What you see: Suggestion chips under the box, and a gallery grouped by category — Animated, Portfolio, Commerce, Dashboard and the rest. A selected template stays pinned near the prompt with its palette, so you can see what you are building on, and you can clear it again.
If it does not go to plan: A vague first prompt still produces a working starting point — you keep steering it in chat afterwards, so do not agonise over wording.
Answer the scoping questions in chat
A new project opens in chat first. The agent asks about the parts of your idea it cannot guess — who signs in, what gets stored, whether money changes hands — and fills in a blueprint as you answer.
What you see: A Blueprint control in the project header. It stays labelled Blueprint while the scope is still thin and changes to Review blueprint once the agent thinks it has enough to build from.
Review the blueprint and choose a build quality
Opening the blueprint shows what is about to be built and which services it will use, with each one marked as managed for you or connected under your own account. You also choose how much effort the build should spend: Prototype is the fastest and cheapest with fewer checks, Standard is the balanced default, and Best researches current practice and reviews more before shipping.
What you see: A confirm action that reads Confirm & start building once the scope is ready, and Keep refining the scope… while it is not.
If it does not go to plan: Nothing here is permanent. You can change anything after the first build — the blueprint is a starting point, not a contract.
Watch it build, then open the preview
Confirming starts the first run. Your project gets a sandbox — an isolated container that holds the code and runs the dev server — and the Preview tab renders whatever is running inside it. This is your real app, not a mockup.
What you see: A boot panel with a terminal streaming the steps: claiming a container, booting the runtime, installing dependencies, starting the dev server. The first start provisions the container from scratch, which can take up to a minute.
If it does not go to plan: If the boot fails, the start control turns into a retry. The terminal output above it names the step that failed.
Iterate in chat, and visually in Studio
Keep describing changes in chat the way you would to a colleague. For design work, the Studio tab is the visual surface: it has a live mode where you arm element selection, click the thing you mean in the running app, and describe the change against that focus instead of explaining where it is on the page. You can also attach a reference image to a message when you want the agent to match a look.
What you see: The preview updating as changes land. The Preview tab itself keeps just two controls — refresh, and open the running app in a new tab — because selection moved to Studio.
Check what actually got built
Repository → Features lists every feature the agent has built for the project and whether the most recent build confirmed it still works. A passing build re-verifies the whole list; a failing one flags what it touched. Repository → Changes shows the history of accepted states.
What you see: A feature list with a verification status against each entry.
Go Live for a public URL
Repository → Deploy carries the Go Live action. It ships the current build to production hosting on Cloudflare and gives the project a real, public address over HTTPS. Once a project is live the same button becomes a redeploy, so publishing is something you do continuously rather than once.
What you see: A deployment status card with the live URL, when it last shipped, the sandbox preview URL, and the Cloudflare project — which is provisioned on the first Go Live.
If it does not go to plan: Every attempt is written to the deploy history on the same tab, including the failures, so you can see what shipped and when.
Build a landing page for a neighbourhood bakery.
Show today's specials, an order form, and an email signup.Scaffolding the project…
Wiring an orders table (Postgres) + email signup (Resend).
✓ Live preview ready — open it and keep describing changes.What gets provisioned for you
Services are created when your prompt actually calls for them, on established providers rather than bespoke infrastructure — so a simple page stays simple.
- Managed Postgres database on Supabase
- Authentication and user sessions
- Transactional email through Resend
- Stripe checkout and subscriptions
- Hosting, builds and HTTPS on Cloudflare
Details on each of these live under integrations.
Start freeQuickstart · edit path
Connect a codebase and ship a reviewed pull request
Already have a repository? Point the agent at it. It indexes the code, works in an isolated clone, verifies its own changes against your real gates, and hands you a pull request to review.
Open a GitHub project
The workspace navigation has an entry for opening a GitHub repository. Connect your GitHub account and it lists the repositories you can reach so you can open one in a click — or skip that and paste a repository directly. Both the full https://github.com/owner/repo URL and the shorter owner/repo form are accepted.
What you see: A note that access is requested only to clone and import, and that your token stays server-side. Private and archived repositories are labelled in the list.
If it does not go to plan: Connecting repositories and opening pull requests is listed on the Pro plan. Check the plan comparison if the option is not available to you.
Let the import finish bringing the project up
Import is a sequence, and the overlay names each stage as it happens: cloning the repository, loading the code into the editor, reading the codebase, installing dependencies, and starting the live preview. Reading the codebase builds two complementary indexes — a semantic one of what the code does, so you can ask for behaviour without knowing file names, and a symbol-aware one of definitions and references, so the agent can see what a change will ripple into.
What you see: Repository → Structure, generated for connected repositories, describing entry points, routes and the modules everything else depends on.
If it does not go to plan: Your local .env is gitignored, so it never arrives with the clone. Expect the environment keys to start empty — step five deals with that.
Describe the change
Ask for a feature, a fix or a refactor in plain language. Because the index is semantic, you can describe the behaviour you want changed rather than pointing at a file — "where do we calculate the cart total" is a usable instruction.
What you see: The agent working through the task in chat, with the files it is reading and editing.
The agent edits inside a sandbox clone
No edit happens in your repository. Work is done in an isolated clone, which is why an unfinished or wrong change can never reach your branches.
What you see: Repository → Changes, which states the rule plainly: a connected repository only ever changes through a reviewed pull request.
Fill in the secrets the app needs to run
If the project needs credentials to run, Manage → Environment lists the keys it declares, grouped by the provider that needs them, each marked set or missing. Paste values there, or paste a whole .env at once. Manage → Connections is the sibling surface: connect a provider account and it can fill some of those keys for you.
What you see: A missing-secret warning on the Manage tab, and a banner over the preview reading that a number of required secrets are missing and the preview may not fully work.
Verification runs before you look
Typecheck, your test suite and a full build run against the change inside the sandbox. If a gate fails the agent keeps working there rather than handing you something broken.
What you see: The run recorded under Manage → Usage with its verdict and what it cost.
If it does not go to plan: A run that cannot get to green is still recorded. Read the failure in chat and reply with the missing context — a needed environment value, a convention it got wrong, a test that was already red.
Review and merge the pull request
You get an ordinary pull request against your repository: a diff scoped to the task you asked for, with the checks already run. Read it, ask for tweaks, merge when it looks right. You remain the reviewer of record and nothing lands without you.
What you see: The PR in GitHub, exactly as you would see one from a colleague.
connect github.com/acme/dashboard
indexing the codebase…
task "add CSV export to the reports page"→ editing in an isolated sandbox clone
✓ typecheck · ✓ tests · ✓ build
→ opened a pull request — scoped to the task, ready for reviewNothing merges without you
All work happens in a sandbox clone and lands as a pull request. You stay the reviewer of record, and you can scope the connection to specific repositories and revoke it whenever you like.
Why the indexing step matters
Semantic indexing lets you describe behaviour instead of naming files. Symbol-aware indexing tracks definitions and references across the repository, so a change accounts for everything that depends on it. Both are covered in code intelligence.
Reference
Core concepts and glossary
A short vocabulary makes the rest of the documentation readable. These are the words the product uses in its own interface, defined once here so nothing later has to explain itself.
Project
One app. A project owns its own code, its sandbox, its preview, its environment values and its deploy target. The free plan covers one active project; paid plans lift that.
Workspace
The set of tabs around a project: Editor, Chat, Preview, Studio, Repository, Agents and Manage. Repository groups Changes, Structure, Features and Deploy; Manage groups Environment, Connections, Usage and Ownership.
Sandbox
The isolated container your project is edited and run in. It is not your laptop and not your repository, which is what makes an in-progress change harmless.
Preview
The dev server running inside the sandbox, rendered in the Preview tab. It is billed per second while running and sleeps on its own after about five minutes with no activity — an idle window, not a countdown from when you started, since every request resets it.
Run
One pass of agent work — plan, edit, verify. Each run is recorded with what it consumed and whether it was accepted, which is what the Usage tab counts as builds run and builds shipped.
Blueprint
The scope summary for a project still being drafted: what will be built and which services it will use. It fills in as you answer questions in chat.
Build quality
How much effort a build is allowed to spend. Prototype is fastest and cheapest with fewer checks, Standard is the balanced middle, Best adds research into current practice and extra review before shipping.
Go Live
The action on Repository → Deploy that ships the current build to production hosting on Cloudflare and returns a public HTTPS URL. On a project that is already live, the same action redeploys. It publishes a static build, so every project generated here can go live; an imported repository can only go live if it builds to static output.
Pull request
How a connected GitHub repository changes. The agent works in a sandbox clone and opens a PR; you review and merge it. The agent never pushes to your branches — the one thing that writes to main without a PR is a progressive rollout you promote yourself.
Connection
A provider account attached to the project on Manage → Connections. A connection can fill the environment keys that provider needs, either under your own account or under a managed one.
Credits
The units usage is metered in, split into build credits and runtime credits. Your plan carries a monthly allotment; the balance, the ledger and the per-run cost all live on Manage → Usage.
Agent
The worker that plans, edits and verifies. The Agents tab also covers the automatic repair that runs on every build and the standing agents you can switch on to watch a lifecycle, a URL or a business event.
Every one of these has a longer page behind it under capabilities.
Guide
Working with the live preview
The preview is your project actually running — a dev server inside its sandbox, not a rendering of one. Understanding when it starts, when it sleeps and what it costs is most of what you need to know about it.
Starting and waking it
Opening the Preview tab on a sleeping project starts the sandbox for you, with a start control and a terminal that streams the boot steps beside it. The first start of a project provisions a container and installs dependencies, so it is the slow one — later starts are warm. If a boot fails, the control becomes a retry.
Editing what you can see
Element selection lives on the Studio tab rather than here. Studio has a live mode where you arm selection, click an element in the running app, and describe a change scoped to that focus. The Preview tab itself deliberately keeps only two controls: refresh, and open the running app in a new browser tab.
When a secret is missing
If required environment keys have no value, a banner sits over the preview saying how many are missing and warning that the preview may not fully work. It links straight to the Environment tab so you can paste them.
Booting the preview…· claiming a sandbox container…
· booting the runtime…
· installing dependencies…
· starting the dev server…
· almost there — finishing the first boot…What a running preview costs you
The sandbox is billed per second while it is awake, and it puts itself to sleep after about five minutes with nothing hitting it — you do not have to remember to stop it. That five minutes is an idle window rather than a countdown from when you started: loading the preview, the agent running a tool, and the workspace held open while you work all reset it, so a sandbox you are actively using stays up and one you have walked away from does not. That consumption is metered as runtime credits, separately from the build credits the agent spends thinking.
- Starting a cold sandbox is the slow path; warm restarts are quick
- Sleeping costs nothing — waking it is a single action
- A deployed site stays up regardless of the sandbox
- Per-run and per-project spend is itemised on the Usage tab
Guide
Connecting a GitHub repository
Bringing an existing codebase in is a one-way, read-and-rebuild operation: the repository is cloned into a sandbox, understood, and reconstructed as a project you can keep working on. Your remote is untouched until a pull request is merged.
What the import actually does
- Clones the repository into an isolated sandbox
- Detects the stack so it knows how to install and run it
- Indexes the codebase semantically and by symbol
- Rebuilds the project's features, structure and docs
Accepted forms are the full repository URL or the shorter owner and repository name.
Connections versus environment values
These are two different surfaces on the Manage tab and it is worth keeping them straight. Connections attach provider accounts — GitHub, and the services your app talks to — and a connection can fill the keys that provider needs. Environment is where the keys themselves live, including everything no provider can supply. A key filled by a connection is shown as coming from it rather than as something you typed.
A connection can run under your own account, which you own from day one, or under a managed one that can be handed over later. The Ownership tab records what is provisioned where, with each provider id, so a handover is a first-class operation rather than a migration.
open https://github.com/acme/dashboard✓ cloned into an isolated sandbox
✓ stack detected — install and dev commands resolved
✓ codebase indexed — semantic + symbol graph
✓ features, structure and docs rebuilt
→ ready: open the project and describe a changeThe guarantees worth knowing
- Edits happen in a clone, never in your working repository
- Changes reach you as a pull request, never as a push
- Typecheck, tests and build run before the PR opens
- Access is scoped to the repositories you authorise, and revocable
More on the mechanics in the GitHub PR agent and sandbox verification.
Guide
Environment variables and secrets
Anything your app needs at runtime and cannot hold in source control lives on the project's Manage tab, under Environment. It lists every key the app declares, grouped by the provider that needs it, each marked set or missing.
How values are stored and used
- Every value is stored encrypted on the server and injected into your running preview. A secret is never read back to the browser — a key that already has a value shows a mask and an option to clear it.
- Each key is either a secret or a plain variable. Secrets are hidden; variables stay visible and editable, which is what you want for anything that ends up in client-side code.
- On a bulk import, publicly-prefixed keys — the NEXT_PUBLIC_ and VITE_ families — are stored as visible variables, and everything else is stored as a secret.
- Pasted .env text is parsed mechanically by the server. Comments and blank lines are ignored, quoted values are unquoted, and no model ever sees the contents.
- Keys a connected provider can supply are filled from that connection instead, and show as coming from it rather than as something you typed.
DATABASE_URL="postgres://…"
STRIPE_SECRET_KEY=sk_live_…
NEXT_PUBLIC_SITE_URL=https://example.com
# comments and blank lines are ignored✓ parsed mechanically — no model reads these values
✓ NEXT_PUBLIC_* stored as a visible variable
✓ everything else stored encrypted as a secret
✓ injected into the running previewWhy an imported project starts with nothing set
Your local .env is gitignored, so it is never part of what gets cloned. That is not a bug in the import — it is the reason the bulk paste exists. Expect to fill the list once, right after an import, and then rarely touch it again.
.env — and that file is wiped whenever the container recycles, which is why it is written again on every fresh start.Guide
Custom domains and deployment
Deploying is one action, and it lives on the Deploy tab inside the Repository group. Going live promotes the build you have been previewing to production hosting on Cloudflare — the app you reviewed is the app that ships.
Going live
The deployment status card is the whole picture: the live URL, when it last shipped, the sandbox preview address, and the Cloudflare project — which does not exist until your first Go Live and is provisioned then. Once a project is live the same action becomes a redeploy, so shipping is continuous rather than a one-off ceremony.
- Every attempt is written to the deploy history, failures included
- HTTPS is handled for you on every address
- Hosting runs under a managed account, transferable later
- A live project can be listed publicly on the showcase, if you want it to be
Which projects can go live today
Go Live publishes a static build to Cloudflare Pages, so what it can ship depends on how your project builds. Every project generated here is a Vite app and goes live without qualification — this is the ordinary path and there is nothing to check.
A repository you imported goes live only if it builds to static files. Vite, Create React App, Astro, SvelteKit, Vue CLI, Angular and plain static sites are deployable today. A framework that needs a server at runtime — Next.js, Nuxt, a Node service — is not yet, and neither is a monorepo: the preview still runs it and the agent still opens pull requests against it, but Go Live returns a plain refusal saying so rather than shipping something broken. Those paths are being built.
- Generated projects: always deployable
- Imported static-output repositories: deployable
- Imported server frameworks and monorepos: preview and pull requests work, Go Live does not yet
Rolling out gradually
The same tab offers a progressive rollout: route a slice of traffic to a new build, watch how it behaves, then widen it or pull it back. It is the safer path for a change you are not certain about, and it is worth using before a risky release rather than after one.
Attaching your own domain
A domain can only be attached to a project that is already live, so go live first. Enter the hostname you want to serve from, and the panel returns the single DNS record to create at your registrar. It then reports the status until the domain goes active, and you can ask it to re-check rather than wait.
- Deploy the project so it has a live URL
- Enter the hostname and attach it
- Create the DNS record the panel shows, at your registrar
- Wait for it to report active — certificates are automatic
You keep the domain and buy it wherever you like; only its DNS points here. See custom domains.
Type CNAME
Name app (or @ on a root domain)
Value <your project>.pages.dev
# the panel shows the exact values for your project — copy them from there● pending — the record has not been seen yet
● active — serving from your domain over HTTPSGuide
Workspace monitoring and health checks
Shipping is not the end of the job. A project keeps correcting and reporting on itself after it goes live, so a broken build or a bad deploy surfaces on its own rather than waiting for someone to notice.
Automatic repair on every build
Every build self-corrects before you see it. It verifies typecheck, tests, the production build and runtime errors, repairs what failed and re-checks — with a behavioural pass and a visual pass alongside. A build is accepted only when it is green and in scope; otherwise it is held for your review rather than shipped broken.
Standing agents you switch on
Alongside that automatic pass, the Agents tab lets you turn on agents that keep watching after the build ends — over a project lifecycle, a URL, or a business event, around the clock. Open alerts surface on the same tab.
Checkpoints you can rewind to
Every build checkpoints the code, and Repository → Changes keeps a version history you can rewind the sandbox to. The current state is snapshotted before a rewind, so the rewind itself is reversible; where the project has a provisioned database, its data is snapshotted and restored alongside the code.
Feature-level verification
Repository → Features is the honest ledger of what exists. A passing build re-verifies every feature on the list; a failing one flags what it touched.
A record of everything that shipped
Repository → Deploy keeps a deploy history: every Go Live, what shipped, when, and whether it failed. It is the first place to look when you need to identify a bad release.
Usage you can actually read
Manage → Usage shows builds run, how many shipped, total spend and the last build, plus a per-run breakdown and the credit ledger for the account.
At a glancebuilds run · every run the agent has made
shipped (accepted) · how many of them landed
total spend · itemised per run, not estimated
last build · when it happenedReading the credit picture
Credits come in two buckets — build credits for the agent's model work, runtime credits for the compute your sandbox uses. Your plan carries a monthly allotment, and the Usage tab shows the balance against it plus an immutable history of grants and deductions. Plan, balance and top-ups are managed for the whole account rather than per project.
Third-party provider subscriptions billed to you directly are estimated separately on the same tab, so infrastructure you pay for yourself is never conflated with credits. The account-level billing page is where the plan itself, the balance and one-time top-ups are managed.
Compare plansReference
Troubleshooting common problems
Most problems are one of eight things, and nearly all of them are diagnosable from the workspace itself. Find the symptom, work down the checks in order.
The preview will not start
- A cold start provisions a container and installs dependencies — give the first boot up to a minute before assuming it is stuck.
- Read the terminal in the boot panel. It names the step that failed rather than just reporting failure.
- If the start errored, the button turns into a retry. A second attempt clears most transient container problems.
The preview loads but a feature is dead
- Look for the missing-secrets banner over the preview. It counts the required keys that have no value.
- Open Manage → Environment and fill anything marked missing.
- If the value should come from a provider account rather than a paste, attach it on Manage → Connections instead.
The preview looks stale or has gone blank
- While a build is running, the preview deliberately keeps showing your last stable version and labels it as such, then refreshes itself when the build finishes — so you never watch a half-built page. Stale during a build is the intended behaviour.
- Use the refresh control on the preview before anything else — a hot reload can drop a frame.
- The sandbox sleeps after about five minutes with nothing hitting it, so the first visit after a break may need it started again. Anything that touches it — loading the preview, the agent running a tool, the workspace held open while you work — resets that clock, so it only sleeps once you have genuinely stopped.
- Open the app in a new tab from the preview controls to rule out an iframe problem.
A build failed or the agent could not finish
- Verification runs typecheck, tests and a build in the sandbox, so the failure is a real one — it is not a formatting complaint.
- The run is still recorded on Manage → Usage with its verdict, so you can see what it did before it stopped.
- Repository → Features flags what a failing build touched, which is usually the fastest way to see the blast radius.
- Reply in chat with the missing context — a value it did not have, a convention it got wrong, a test that was already red.
An imported repo looks empty or wrong
- Import clones the repository, detects the stack, indexes the codebase and rebuilds features, structure and docs. Let it finish before judging it.
- Repository → Structure is generated for connected repositories — if it is empty, the import did not complete.
- Confirm you pasted the right repository. Both https://github.com/owner/repo and owner/repo are accepted, so a typo is easy to miss.
None of my environment values came across
- This is expected. A local .env is gitignored, so it is never part of the clone.
- Use the .env import block on Manage → Environment to paste the whole file in one step.
- Anything a provider can supply is better attached as a connection than pasted by hand.
My custom domain is stuck pending
- The domain only goes active once the DNS record shown in the panel exists at your registrar. Check the type, name and value character for character.
- The panel polls on its own and also offers an explicit status check if you do not want to wait.
- On a root domain, registrars that refuse a CNAME at the apex need their CNAME-flattening or ALIAS record instead — the panel says so when it applies.
- DNS propagation is outside anyone’s control. If the record is right, the remaining variable is time.
A deploy shipped something broken
- Repository → Deploy records every Go Live — what shipped, when, and whether it failed — so you can identify the bad one.
- Repository → Changes holds a version history of build checkpoints. Rewinding the sandbox snapshots the current state first, so the rewind is itself reversible.
- Use progressive rollout to route a slice of traffic to a new build, watch it, then widen it or pull it back.
- Fix forward in the preview and redeploy; the live site follows the same one-action path it did the first time.
When none of that fits
The chat inside the project is the fastest help you have — it can read the run that failed and the code that produced it, which no written description can match. Describe the symptom there before anything else. For questions about accounts, plans and billing, the pricing page and the community are the right places to start.
FAQ
Documentation questions, answered
Where to next
Keep exploring
Platform
Both paths end to end — prompt to preview to Go Live, and repo to sandbox to reviewed PR.
Learn moreCapabilities
A page per building block: prompt to app, live preview, Go Live, managed backend, sandbox verification and more.
Learn moreIntegrations
What is built in — Supabase, Stripe, Resend, GitHub, Cloudflare — and what you connect yourself.
Learn moreAgents
Continuous and scheduled health checks, alerts, auto-recovery and rollback.
Learn moreTemplates
Complete design systems with starter code, so a build does not begin on a blank page.
Learn morePricing
What each plan includes, which features unlock where, and how credits are described.
Learn moreStart your first build.
Describe an app or connect a repo — free to try, with nothing to configure.