Apps

An App is a public-facing site built from a Wapp — bound to some of its collections and workflows, deployed to a generated <slug>.cheqq.site address. Where a Wapp is always private to your workspace, an App is how you expose part of it to teammates, invited guests, or the open internet.

Nothing is exposed by default

An App only ever sees what you explicitly connect to it. There's no implicit access to the rest of the Wapp's data — every collection and every workflow an App can touch has to be deliberately bound, and even then, only the fields and operations you allow are reachable. If you haven't bound something, the App can't see or call it, full stop.

Audience

Every App has an audience tier that controls who can open it:

See Audience and bindings for how audience interacts with what an App is allowed to do.

Bindings

Two kinds of bindings connect a Wapp's internals to its App:

• Data bindings — bind a collection, choose which operations are allowed (read, insert, update, delete), and pick exactly which fields are exposed and which of them a visitor may change. Every binding names at least one field. A binding can also hold a collection to the signed-in visitor, so each person sees only their own records: that's how a portal works.
• Logic bindings — bind a workflow's webhook trigger, so the App's frontend can call it directly.

Full permission model in Audience and bindings.

Build and deploy

You build an App by describing it in the App Builder's chat; Cheqq writes the code, starting from a template with Tailwind CSS ready to use. The build setup is Cheqq's, not the App's: build plugins come only from a short reviewed list, and packages install from the public npm registry with nothing else in reach.

An App's code reaches your data only through its bindings, so code that asks for a field or operation the App wasn't granted fails the build instead of failing in front of a visitor. Before deploying, the builder opens the draft in a browser, exercises it, and fixes what it finds — see The builder checks before it ships.

Publishing compiles a static build of its pages. A deployment moves through draft → building → deployed (or failed, if the build errors). Earlier versions stay available, so a failed or unwanted deploy can be rolled back instantly. Pages are prerendered by default, which is better for search; ask the builder for a single-page app instead when that suits the App better.

Every page an App serves says where its scripts, styles, and connections may come from and which pages may frame it — its own address and Cheqq, for a published App.

Each deploy of a Public App also takes a cover picture of it as a signed-out visitor sees it, so a picture of the App shown to strangers never includes anything only you can see. The cover is removed if the App stops being Public.

Apps that come with a template

A business system from the Store installs its Apps with it, such as a booking form, a menu site, or a client portal, already bound to its own records and automations. You publish them from the Wapp's Home. See Apps that come with a template.

Branding and custom domains

An App that isn't Public shows visitors a sign-in screen you can brand, and any published App can connect a custom domain on top of its generated *.cheqq.site address. See Branded auth and domains.

Where to go next

• Audience and bindings — the permission model in depth
• Branded auth and domains — sign-in screens, sessions, and custom domains
• Manage an App — create, configure, and publish an App