Skip to content

Getting started

From sign-up to a deployed app: create a project, build it in chat, preview it, ship it.

1. Create an account

Sign up at /signup with an email address and a password. Where they are enabled you can also sign in with GitHub or with Cloudflare; signing in with Cloudflare connects your account for deploys right away. If email verification is on, confirm your address from the email we send before you can sign in.

Your account includes a workspace where you can create projects and follow your usage.

2. Create a project

From the dashboard, choose New project. Give it a name and decide what the app needs:

  • Database (D1): on by default. The template ships with a Drizzle schema, a first migration and a working example table.
  • Website media (Filebase): optional during onboarding. New projects save available business photos automatically without requiring Filebase. Connect Filebase for your own photo storage and uploads from the owner admin.

In Filebase, open Access keys. Copy your Access token and Secret key into the project's photo storage settings. Keep both values private. Filebase stores website media separately from your Cloudflare resources.

The name becomes a URL-safe slug (for example Invoice tracker becomes invoice-tracker). The slug is the name of the Worker on your Cloudflare account and of the URL it gets on workers.dev, so it has to be unique among your projects. A project is seeded from the LeadMax template:

app/            layout.tsx, page.tsx, actions.ts, api/health/route.ts
components/ui/  button, card, input (shadcn-style, Tailwind v4)
lib/env.ts      the only file that touches Cloudflare bindings
lib/db.ts       Drizzle on D1        lib/schema.ts   your tables
migrations/     0001_init.sql, applied in order
vite.config.ts  wrangler.jsonc  leadmax.json  package.json

Its first snapshot is revision 0, so you can always get back to a clean template.

3. Open the editor

The editor has the chat on the left and one large pane next to it with two tabs: Preview (the running app, with a collapsible terminal for the dev-server output) and Code (file tree and editor). The Deploy button and the history icon in the header open a third pane on the right with the deploy status and the version history. When the editor opens, your browser boots a WebContainer, mounts the project, installs its dependencies and starts the dev server. Expect the first boot to take a moment:

StepTypical time
Install dependencies6 to 20 seconds
First page render (the bundler runs as WebAssembly)4 to 14 seconds
Every change after that (hot reload)about 100 milliseconds

Browser support depends on shared memory, WebAssembly and available device memory. See Supported browsers.

4. Build in chat

Describe what you want. The agent reads the relevant files, then writes, edits or deletes files one at a time. Each file operation is applied to the preview as it streams in, so the app updates while the agent is still working. When a turn touches files it ends with a snapshot: a new revision you can restore later.

Some things that work well:

  • Ask for one feature at a time, and mention data when it matters ("store bookings in D1").
  • Refer to files by name if you know them; the agent sees the same tree you do.
  • Edit code yourself in the code pane. If the agent changed the same file meanwhile, the editor shows a diff instead of overwriting.

Each turn updates your available credits; your balance is shown next to the composer. Details in Credits explained.

5. Fix errors

The dev server's output and runtime errors from the preview are collected in the editor. Choose Fix it to send them to the agent with the files involved. The agent only ever edits files; it has no shell and cannot run commands in your preview.

6. Preview data

In the preview, env.DB and env.CACHE use local D1 and KV data. Migrations run when the preview boots. This data stays separate from your deployed database; reset it from the editor for a clean start.

7. Versions

Every snapshot is listed in the project's version history with its message and author (you or the agent). Restoring a version mounts that revision into the preview and records a new snapshot, so restore itself is reversible. Deploys always reference a specific revision.

8. Deploy

Open the Deploy panel in the editor. The first time, it asks you to connect your Cloudflare account (you can also do that from Settings); then deploy the current revision. The status moves through building, queued, migrating, uploading and live, with the build log attached. The first deploy of a project creates its resources on your account and turns on its workers.dev URL; later deploys reuse them. What is created and why is described in What gets created on your account.

Rollback

Deploying an older version from the history is the rollback. The same pipeline runs, migrations included.

9. Take the code with you

A new project is a standard Waku project. Choose Download source (.tar) in the project settings (the project name in the editor header, or the project's menu on the dashboard) to get the current files, or the download icon next to any revision in the Versions panel for an older one. Unpack the tarball and run it with the same commands the template documents: LEADMAX_PREVIEW=1 pnpm dev for the local preview mode, pnpm build for a production build for Workers.

Source downloads contain the project files, not a separate copy of photos stored by LeadMax or Filebase. A site using LeadMax-hosted photos keeps that media dependency after export. Before leaving LeadMax or deleting the project, copy those images to your own storage and update their URLs. Keep any configured Filebase connection for photos stored there.