Build ON The Cloud

Build an app or widget inside The Cloud — described or coded, hosted by us, sandboxed by default, scoped by manifest, listed through the share gate. Idea to installable in under 10 minutes.

Read as Markdown

Build ON The Cloud

You want an app or widget living inside The Cloud. A Studio app is a real multi-file app — you describe it or code it, The Cloud hosts it, it runs sandboxed by default, it is scoped by a manifest, and it lists through the share gate. You never own a server.

Note

What you need

An AI client connected to The Cloud over MCP (Claude Code, Claude Desktop, Cursor, or any MCP client) and one idea. That is the whole toolchain — the build tools live on the MCP endpoint, so your AI drives them for you.

Quickstart

Connect your AI to The Cloud One line. The browser opens once to sign in — no secret is copied or stored. Full options on the Connect INTO The Cloud page.
```
claude mcp add --transport http the-cloud https://mcp.thecloud.so/mcp
```
Ask it to build the app Describe what you want. Your AI calls createStudioApp to scaffold a real multi-file app in your workspace, then writes the files with writeStudioAppFile.
```
Build me a Studio app: a tip calculator with a clean, calm UI. Keep it single-page.
```
See it running The app is already hosted. Your AI calls renderStudioApp to headlessly screenshot it and read back any console errors, and checkStudioApp for route health — so it can verify the app works before handing you the link. Open that link and it is live.
Iterate — the dev loop Ask for a change. Your AI edits files with editStudioAppFile, re-renders to verify, and the hosted app updates. Run lintStudioComposition to confirm the app keeps its scroll-shell guarantee. This is the whole loop: edit → render → verify.

Manifest and scopes

A Studio app declares what it may reach in its manifest. Your AI edits it with editStudioAppManifest. The manifest names a closed set of capability scopes; the tools the app may call are a subset of what those scopes imply, brokered per call through a single choke point.

Deny by default. An app can reach nothing consequential until its manifest requests the scope and you grant it.
Destructive tools are held higher. They require an explicit per-tool grant and pass human review at the share gate — never a blanket scope grant.
The broker is the only door. The app talks to The Cloud through the postMessage broker; it has no ambient network egress (sandboxed with connect-src 'self').

Hosting

There is nothing to deploy. The Cloud hosts the app the moment it exists, serving it sandboxed from an opaque origin. Framework hosting handles the build. Host-for-you is the headline — you keep writing the app, not the infrastructure.

List it

Everything you build is Private by default. When you are ready to share, your AI calls shareStudioApp or setStudioAppVisibility — and because publishing widens exposure, it only takes effect once you approve it in The Cloud. Approved apps list in Explore, where others can discover and adopt them.

Note

Consent is a floor, not a setting

An AI can request a share; it can never self-approve one. The same rule protects every app you build. Read the whole model on the Safety classes & the consent law page.

Where to go next

Connect INTO The Cloud — the other golden path: make your own service a tool here.
Tool reference — every Studio tool, generated from the live registry.
Safety classes & the consent law — the governance that makes the platform trustworthy.

Build ON The Cloud

Note

What you need

Quickstart

Connect your AI to The Cloud One line. The browser opens once to sign in — no secret is copied or stored. Full options on the Connect INTO The Cloud page.

claude mcp add --transport http the-cloud https://mcp.thecloud.so/mcp

Ask it to build the app Describe what you want. Your AI calls createStudioApp to scaffold a real multi-file app in your workspace, then writes the files with writeStudioAppFile.

Build me a Studio app: a tip calculator with a clean, calm UI. Keep it single-page.

See it running The app is already hosted. Your AI calls renderStudioApp to headlessly screenshot it and read back any console errors, and checkStudioApp for route health — so it can verify the app works before handing you the link. Open that link and it is live.

Iterate — the dev loop Ask for a change. Your AI edits files with editStudioAppFile, re-renders to verify, and the hosted app updates. Run lintStudioComposition to confirm the app keeps its scroll-shell guarantee. This is the whole loop: edit → render → verify.

Manifest and scopes

Deny by default. An app can reach nothing consequential until its manifest requests the scope and you grant it.

Destructive tools are held higher. They require an explicit per-tool grant and pass human review at the share gate — never a blanket scope grant.

The broker is the only door. The app talks to The Cloud through the postMessage broker; it has no ambient network egress (sandboxed with connect-src 'self').

List it

Note

Consent is a floor, not a setting

An AI can request a share; it can never self-approve one. The same rule protects every app you build. Read the whole model on the Safety classes & the consent law page.