Deploy from your browser
One-click Cloudflare deploys from Quickback Start — connect your account, click Deploy, and the hosted broker provisions resources, applies migrations, and ships the Worker. No CLI, no tokens in the browser.
Build a backend in Quickback Start, get a green compile, and ship it to your own Cloudflare account with one click — databases created, migrations applied, secrets minted, Worker live on a workers.dev URL. No local tooling required.
This page covers the browser flow. For local projects, or anything the browser flow doesn't support yet, use quickback deploy — the CLI covers every resource type and is always available.
Browser deployment is rolling out. The hosted deploy service ships fail-closed behind a kill switch while the final authentication work lands; if the Deploy card doesn't appear in Start, your session isn't in the rollout yet. quickback deploy works for everyone today.
Browser vs CLI
| Deploy from Start | quickback deploy | |
|---|---|---|
| Where you work | start.quickback.dev chat | Your terminal, local project |
| Cloudflare auth | OAuth consent (no tokens handled by you) | wrangler login / CLOUDFLARE_API_TOKEN |
| Resource coverage | The supported matrix below, fail-closed | Everything the compiler emits |
| Custom domains | Not yet — workers.dev only | Yes, via your wrangler.toml routes |
| Best for | Chat-built apps, first deploys, demos | Local development, full-featured apps, CI |
How a deploy runs
When you click Deploy this app, the pipeline runs four phases and reports each one:
- Compile — your project compiles on the hosted compiler and emits a deployment manifest: the exact set of resources, migrations, and secrets the deploy will touch. Anything the browser flow can't deploy fails here, with a named reason — never as a half-deployed app.
- Provision — each D1 database, KV namespace, and R2 bucket is created in your account, or adopted if a resource with the same name already exists. Retries and redeploys never create duplicates. Nothing is ever deleted automatically.
- Package — the project recompiles with the real resource ids folded in and is bundled into Worker modules (plus your CMS/Account SPA assets, when enabled). Every byte is hash-verified against the manifest before anything is uploaded.
- Finalize — migrations apply, the Worker uploads with its bindings, secrets are set, and the
workers.devroute is enabled. Start probes the URL and only shows Live once it actually answers.
A typical deploy takes one to two minutes, most of it compilation.
What deploys
Supported today, end to end:
| Resource | Notes |
|---|---|
| D1 databases | All of a project's databases — auth, features, and (when your features pull them in) audit, webhooks, and file-metadata |
| KV namespace | The KV binding for rate limiting and session overflow |
| R2 bucket | Managed file storage (managed: true) |
| Realtime | The inline Broadcaster Durable Object, including its class registration |
| Email binding | The Cloudflare Email Service binding is attached (see the delivery caveat below) |
| CMS / Account UI | The bundled SPAs upload as static assets on the same Worker, with your app's real URL baked in |
Blocked, fail-closed at the compile phase — the deploy stops with the reason, and quickback deploy remains the path for these:
| Blocked | Why |
|---|---|
| Webhooks, embeddings | Need queue and Workers AI bindings the broker can't create yet |
| Vectorize | Not yet supported |
| Neon / Postgres | Browser deploys are D1-only; Neon projects deploy via the CLI |
| Separate-worker realtime | Needs a second Worker + service binding |
Custom apps: mounts | Typically need custom domains |
Custom bindings: (Durable Objects, queues, services, extra R2 buckets) | Not represented by the deploy contract yet |
| Secrets you supply (third-party API keys, etc.) | The browser flow has no way to collect them yet — a project that requires one is refused rather than deployed broken |
| Hyperdrive, public R2 buckets, containers, workflows | Out of MVP scope |
Email delivery: the email binding is attached so your app boots and auth works, but actually sending mail requires Email Sending to be configured on your Cloudflare account with a verified sending domain — which a fresh workers.dev app doesn't have. Start's builder defaults new apps to email + password without email verification for exactly this reason; enable verification, OTP, or magic links after you've configured a sending domain.
Connecting your Cloudflare account
The first deploy starts with Continue with Cloudflare — a standard OAuth consent against Cloudflare's own dashboard, shown by the Quickback OAuth client. You pick the account, see exactly which permissions are requested, and can revoke at any time from Cloudflare under My Profile → Access Management → Connected Applications (or disconnect from Start).
What's requested, and why:
| Scope | Used for |
|---|---|
openid, user-details.read | Identifying the connection (your email is stored masked, e.g. p***@example.com) |
memberships.read | The account picker — so you never copy a 32-character account id |
account-settings.read | Looking up your workers.dev subdomain to build your app's URL |
workers-scripts.write | Uploading the Worker, enabling its route, setting its secrets |
d1.write | Creating databases and applying migrations |
workers-kv-storage.write | Creating the KV namespace |
workers-r2.write | Creating file-storage buckets |
Nothing broader is requested — no zone, DNS, billing, or account-management access.
Where your token lives
The OAuth token never reaches your browser, the chat model, or the compiler. It is held by the deploy service and:
- encrypted at rest with AES-256-GCM under a versioned key-encryption key;
- bound to its connection record (the ciphertext is unusable if copied elsewhere);
- decrypted only inside the API calls of an active deploy, then discarded.
Tokens expire; when one does, Start shows a reconnect prompt and a fresh consent re-issues it onto the same connection. Revoking in Cloudflare kills the token immediately — the stored ciphertext becomes useless.
Secrets on the deployed app
BETTER_AUTH_SECRETis minted by the deploy service — 256 bits of fresh entropy per app — and set on the Worker directly. It's never shown to the browser or stored in your project.- Existing Worker secrets are always preserved. Cloudflare's upload API replaces a Worker's bindings wholesale; the deploy explicitly carries every existing secret across, so a redeploy can never silently delete a secret you set by hand.
Redeploys are safe by construction
Click Deploy as often as you like:
- Provisioning adopts — existing resources are matched by name and reused, never duplicated, never deleted.
- Migrations apply exactly once — a ledger in each database records every applied migration with a content hash. Already-applied migrations are skipped (even when a recompile renames the file), and a migration whose content changed after it ran refuses the deploy outright instead of corrupting the schema.
- Assets are content-addressed — a redeploy with unchanged CMS/Account assets uploads zero bytes.
- Realtime classes register once — Durable Object registrations follow Cloudflare's append-only chronology; a redeploy sends nothing new.
After it's live
Your app answers at https://<app-name>.<your-subdomain>.workers.dev:
- API-only apps serve a small landing page at
/(browsers) and a JSON service descriptor (everything else), linking/api/v1,/openapi.json, and/health— never a bare 404 on first visit. - Apps with the Account UI or CMS redirect
/to the login page or CMS. /healthreports status and whether email is configured.
The deployed app is a normal Worker in your account: logs, metrics, and settings live in your Cloudflare dashboard, and you can take over management with the CLI at any time — download the project from Start and quickback deploy picks up the same resources by name.
Not yet available
- Owner login in deployed apps ("Continue with Cloudflare" as the app's admin sign-in) — the UI half ships with the Account SPA, but the server half and its per-app OAuth client are still in progress.
- Custom domains for browser-deployed apps —
workers.devonly for now. - The blocked resources listed above.
These all work — or will work first — through quickback deploy.
Deploying
One-command deploys with quickback deploy — creates missing Cloudflare resources (D1, KV, R2), writes the real ids back into your config, applies migrations, and ships the worker.
Owner access after a browser deploy
How you become your deployed app's first admin — a one-time claim link, no setup, no standing dependency on Quickback.