Backend bricks

Sometimes you want the built site to serve its OWN database or API — not just read a public URL. Backend bricks ship server logic with your export.

Define an operation

Create a named, parameterized operation bound to a connection. For SQL, a parameterized statement:

-- name: recentOrders
SELECT * FROM orders WHERE customer_id = $1 ORDER BY created_at DESC LIMIT 20

Raw or interpolated SQL is rejected; inputs always bind as $1..$n. Test it with sample input before wiring.

Wire the UI

Place a DataBackend brick (it has no visible UI) listing your operation names. On export, each becomes a serverless function (e.g. /api/op/<name>); UI bricks bind to the results.

Databases on export

• Postgres / MySQL — the export reads the connection string from an environment variable at deploy.
• Cloudflare D1 — a serverless SQLite database that binds automatically; declare its tables once with a schema step.
• Harper — deploying to Harper runs your operations against the cluster's own database in-process, with no separate connection string to manage.

Backend bricks work the same way regardless of host — pick the host when you deploy; the operations you defined don't change.

Secrets

Connection strings and keys are set as environment variables at deploy — the export documents which. Nothing secret is baked into the bundle.

Next steps

• Deploying
• Databases & SQL