Quickback Quickback

POLICY ENGINE

Policy in.
Execution out.

Every Quickback rule — schema, firewall, access, guards, masking, workflow — is a TypeScript declaration. The compiler turns it into the runtime code that enforces it. The policy becomes the execution.

See the pipeline

Five things you declare

These aren't features the runtime layers on. They're things you write in your schema file. The compiler reads them, validates them together, and emits code that can't be called without honouring them.

Declared as

Firewall

q.scope("organization") — every read, write, and Action is auto-scoped. Cross-tenant access becomes uncompilable.

Declared as

Access

{ roles: [...], record: {...} } — role and record-level rules per operation. Deny by default. Compiled into route middleware.

Declared as

Guards

createable / updatable allowlists, plus .protected() columns. Anything else in a payload is rejected before it reaches your handler.

Declared as

Masking

{ type: "email", show: { roles: [...] } } — column-level redaction with role gating. Validator proves at compile time that no view leaks an unmasked column.

Declared as

Workflows

Actions on protected fields, with record-level preconditions. Defines the only legal way state can change. Compiles into REST + MCP + admin UI surfaces with the same enforcement at every entry point. Read more →

The pipeline

From declarative TypeScript to enforced runtime code. Three steps, all at build time.

Step 1 — You write

Declarative policy

A TypeScript file per resource. Plain objects. No DSL.

guards: {
  createable: [...]
},
access: {
  roles: ["admin+"]
}
Step 2 — Compiler

Validation + emission

Resolves rule precedence. Refuses to emit policies that contradict each other or that can be bypassed.

  • · Schema → Drizzle migrations
  • · Access → middleware
  • · Guards → input validators
  • · Masking → response transforms
  • · Actions → typed routes + tools
Step 3 — At runtime

Enforced execution

Standard Hono code on your infrastructure. The policy is the request handler.

  • · Hono routes
  • · Better Auth wiring
  • · MCP tool guards
  • · Drizzle constraints
  • · CMS form gates

Most policy engines work the other way around: code on one side, a runtime evaluator on the other, configuration in between. The two drift. Quickback puts the evaluator in the build step — so the configuration is the code.

We operate at the schema level.

We never connect to your database. We never see your data. We never sit in your request path. The compiler reads your schema and rules, generates the code, and exits.

Schema-level analysis is what makes that possible. The policy engine doesn't need to inspect rows or watch traffic — every rule it enforces is statically derivable from your declaration. Privacy and enforcement live in the same property.

What the compiler emits

Hono middleware

Per-route auth, role checks, record-level preconditions, request validation. Composed in the order the compiler resolved.

Drizzle constraints & migrations

Schema, scope columns, audit columns, soft-delete predicates. Your migrations are a build artifact, not something you maintain.

Better Auth wiring

Auth configuration, organization plugin setup, cross-subdomain cookies — derived from your account & tenancy declarations.

MCP tool guards

Every Action becomes an MCP tool with the same access checks, record preconditions, and structured errors as the REST surface.

Response transforms

Masking applied per role per view. View-to-mask intersection validated at compile time so an unmasked column can't slip into a low-trust view.

CMS form gates

Auto-generated admin UI that respects the same access, record, and protected-field rules. No "admin elevates everything" mode.

Compiled policy vs. runtime policy

Runtime policy engine

  • · Separate service to deploy and operate
  • · Policy file and code can drift
  • · Cold-start and per-request evaluation latency
  • · "What does this policy actually do at runtime?" is a debugging problem
  • · Must trust the runtime to apply the rule on every code path

Compiled policy (Quickback)

  • · No extra service. Your Hono app is the policy.
  • · Policy and code are the same artifact — drift is impossible
  • · Zero per-request policy overhead
  • · The generated src/ shows you exactly what runs
  • · The compiler refuses to emit a code path that bypasses a rule

A compiler doesn't drift. That's the argument.

Try it

Declare your policy in TypeScript. Compile it into a Hono API you own. The output is standard code — Hono, Drizzle, Better Auth — that runs anywhere.

npx @quickback-dev/cli create cloudflare my-app
See workflows in action