The Buildpad Ecosystem
Buildpad is three products that share one project. This site documents the platform. Two more pieces do the work your app actually runs on, and each has its own documentation site.
| Product | Where you meet it | What it owns | Its docs |
|---|---|---|---|
| Buildpad Platform | app.buildpad.ai | Organizations, members, roles, projects, microapps, workers, connectors, builds, and the AI IDE starters | This site |
| Buildpad DaaS | <your-project-id>.daas.buildpad.ai — opened as DaaS Studio from your project | Your project’s data backend: collections, fields, relations, roles and policies, files, event hooks, workflows, cron jobs, and the REST + MCP APIs | docs.daas.buildpad.ai |
| Buildpad UI | ui.buildpad.ai | The React component library your app is built from — forms, tables, field interfaces, file managers — browsable as live Storybooks | ui.buildpad.ai |
The short version: the platform provisions and governs, DaaS stores and enforces, UI renders. Your application code sits in the middle, generated in your own AI IDE from a starter the platform hands you.
How They Fit Together
The Three Handoffs
Everything that ties the products together happens at three points.
1. The platform provisions your DaaS
Creating a project in the platform provisions a DaaS instance for it. The project’s Details page shows its status, and Services & Integrations launches DaaS Studio — the visual editor for that instance. One project means one DaaS backend, shared by the Main App and every microapp in it. See Projects and Microapps.
2. Starters carry the credentials
When you download an AI IDE starter, the platform fills in your DaaS URL and access token for you. That single download wires up three MCP servers, one per part of the ecosystem:
buildpad— the component library and Buildpad conventions, so generated code uses real components.daas— your live backend, so the agent reads your actual collections and fields.buildpad-platform— your org, project, and microapp context.
Workers get the same treatment through their environment file (DAAS_URL, DAAS_TOKEN). See AI IDE Setup and Workers.
3. UI components talk to DaaS
Buildpad UI components are installed into your project as source you own (npx @buildpad/cli@latest), not as a locked dependency. They are built against DaaS shapes — a field’s interface type in DaaS maps to a ready-built component — which is why the hosted Storybooks sign in against a DaaS backend and can render against real schemas.
The platform’s help menu (? in the header, or ⌘ /) links all three documentation sites, and highlights the one that matches the page you’re on. See Navigating the Platform.
Which Docs Answer My Question?
| I want to… | Go to |
|---|---|
| Invite a teammate, set org roles | Platform — Organizations |
| Create a project or microapp | Platform — Projects, Microapps |
| Download a starter, set up my AI IDE | Platform — AI IDE Setup |
| Run a long, heavy background job | Platform — Workers |
| Store third-party API credentials | Platform — Connectors |
| Add a collection, field, or relation | DaaS — Data Model |
| Control who can read or write a record | DaaS — Roles & Policies |
| Query, filter, or paginate my data | DaaS — Items API , Filter Rules |
| Authenticate an API call | DaaS — Authentication |
| Validate on save, cascade a delete | DaaS — Event Hooks |
| Schedule a lightweight recurring task | DaaS — Cron Jobs |
| Upload and serve files | DaaS — Files |
| Find the component for a field type | UI — Interfaces Storybook |
| Build a dynamic form | UI — Forms Storybook |
| Add a file manager to a screen | UI — Files Storybook |
Boundaries Worth Knowing
A few responsibilities look like they overlap. They don’t, quite.
Scheduled work. DaaS cron jobs are for short server-side tasks close to the data. Platform workers are for long-running processes with their own repo, build pipeline, and message queue — reports, transcoding, retry-heavy syncs.
Access control. Platform roles decide who can touch the project — who can invite members or start and stop services. DaaS roles and policies decide who can read and write data at runtime. They’re separate systems for separate audiences.
Where your app runs. Neither DaaS nor the component library hosts your application. You build and deploy it yourself from the starter; both provide services it consumes.