Questions you're already asking

That's what Actions are for. Define typed business operations — approve an invoice, stream an AI response, process a webhook — with the same security guarantees as your CRUD endpoints. Actions get the firewalled database, the user context, and any external service. If you can write it in TypeScript, you can ship it as an action. Actions →

Yes, per action. The build rejects raw SQL by default so it can't sneak past the firewall unnoticed; set allowRawSql: true on the one action that needs it and it goes through, visibly. Drizzle's query builder covers almost everything else. Scoped database →

Several, by design. Actions cover anything beyond CRUD. Every automatic rule has an explicit exception — firewall.exception, access overrides, guard opt-outs — so a single resource can break a default without breaking the model. And the generated output is yours: patch it after a build, branch off entirely, or stop using Quickback and keep shipping with what you have. Quickback is a build step, not a runtime — there's nothing to escape from.

Rebuilding overwrites the generated src/ folder — and that's the point. Your definitions and action handlers are the source of truth. Change a definition, rebuild, and the whole API updates. Action handler files live in your project and are never overwritten; the build wraps them with auth, access checks, validation and org scoping. Output structure →

No. The output is standard TypeScript — Hono routes, Drizzle ORM, Better Auth — deployed to your own Cloudflare account. If you stop using Quickback tomorrow you still have a working codebase on libraries you already know. Nothing runs on our servers; we never see your database or your data.

Cloudflare D1 (SQLite at the edge), Neon Postgres (serverless), and Supabase Postgres. The same definitions build against any of them — pick the one that fits. Databases →

Views. A view is a named field projection with its own access rule — column-level security — served at /api/v1/{resource}/views/{viewName}. Views inherit firewall, access and masking, so a masked field stays masked inside a view, with the same pagination, filtering and sorting as the list endpoint. Views →

The CLI installs a Claude Code skill and Cursor rules, and ships an MCP server that exposes the docs, your config and your feature definitions to any MCP-compatible tool. quickback docs <topic> works from any shell. The build validates every definition, so an agent gets told exactly what's wrong instead of discovering it at runtime. AI tooling →

A guided, in-browser builder at start.quickback.dev. Describe the app; its agent defines the features, runs the build, shows you what it generated, and lets you deploy from the browser or download the project. No install, no signup to try.

A schema-driven CMS that ships inside your Worker when you set cms: true. Every table, column, action, view and security rule renders automatically — data tables, inline editing, action dialogs, role switching, masked fields. Zero UI code per table. Admin UI →

A production-ready auth frontend for any Better Auth backend: login, signup, passkeys, magic links, email OTP, organisation management, roles, invitations and an admin panel. Served from your Worker on its own domain, configured at runtime. Account UI →

Supabase is a hosted platform; Quickback is a build step that emits code you run yourself. It also works with Supabase Postgres as a database target. If you'd rather own the whole stack, the generated project on Cloudflare gives you auth, storage, queues, realtime and vector without a second vendor. Why Quickback →

Quickback is free while in beta. You pay your own Cloudflare (and, if you choose one, database) bill directly — there is no Quickback runtime in the request path to meter. Pricing →