Skip to main content
Capabilities are the pieces of real infrastructure Creator can give your app: user sign-in, a Postgres database, file storage, secrets, email, webhooks, and a public URL. They’re not mocks or shared sandboxes — each one is provisioned for your project alone.

​
When capabilities are created

Nothing is provisioned while the agent is planning. The plan you review before approving includes a capability table — exactly which capabilities the build will create and use. Pressing Approve on the plan review is the moment they come to life. If a later change needs a new capability, the agent requests it and you’ll see it appear the same way.

​
Isolation, in one honest paragraph

Every project gets its own slice of everything: its own database and database role (the database itself refuses cross-project queries), its own storage scope, its own secrets path, its own sign-in user pool, and its own network space. One project cannot read another project’s data — not by policy documents, but because the boundaries are enforced at the database, storage, and network layers themselves.

​
Where you see them

  • The Infra tab in the workspace shows the capabilities bound to the project and their status.
  • The Resources page (reachable from the workspace top bar) is the full live inventory — every provisioned resource, in one place.

​
When a capability needs something from you

Some capabilities can’t finish setting up without a value only you have — for example, a Stripe webhook signing secret, or the client ID and secret for “Sign in with Google”. The product shows this as Needs your secret in the Infra tab, in amber, rather than pretending the setup is done. You paste the value into a dedicated secure field — it goes straight into your project’s secret store. Credentials never travel through the chat, are never shown to the agent as plaintext, and never appear in logs.

​
The capabilities