Build & deploy an app

Build mode (in the dashboard): open an app and use the Build panel at the top, describe a change in chat and the agent reads, edits, tests, and deploys a preview for you, no MCP client needed. It runs on the included models (env.AI.cloudrizz), works on a feature branch, and deploys to a preview URL you review before promoting.

Via an MCP client (this guide): connect ChatGPT or Claude to Cloudrizz over MCP and drive the full tool set below, best for complex work and when you want your own frontier model. The two are interchangeable: both edit the same files, branches, and deploys.

Every app starts with create_app (from: "scaffold"). It creates the app inside your organization and lays down a starter project, a static frontend plus an api/*.js backend running on the edge, with the core platform bindings (env.AUTH, env.DB, env.STORAGE) built in. Attach env.EMAIL and env.AI when you need them.

• create_app, create the app and its main branch.
• list_files / read_file, inspect what was generated.

Code changes are made with edit_file, then snapshotted with save_version, that's a commit. Versioning is built in, so every deploy is reproducible and you can roll back.

• edit_file, write or modify a file in the working tree.
• save_version, commit the current state as a new version.
• list_versions, see the version history.
• list_migrations, review database migrations the app defines.

For larger changes, work on a branch so you can preview without touching production. Each branch deploys against its own throwaway sandbox, separate from live data, and separate from other branches, so a work-in-progress can't corrupt production or collide with a teammate's branch.

• manage_branch (action: create), start a branch off main.
• manage_pull_request (action: open/list/get), propose the change for review; get shows whether the merge is clean.
• merge_pull_request, or manage_pull_request (action: close), land or drop it.
• manage_branch (action: list/delete), list branches, or tear one down when it's done (its commits stay on main).
• reset_playground, wipe a preview sandbox (database and storage); pass a branch to reset that branch's sandbox.

Apps get a database and storage by default. Attach more, and set the environment variables your code reads at runtime.

• manage_resource (action: list/attach/detach), manage optional bindings (cache, AI, email). env.DB and env.STORAGE are always on and can't be detached.
• manage_app_env (action: set/list/delete), manage environment variables (secrets are encrypted and injected at deploy).
• request_upload_url, get a URL to upload a large asset.

deploy_app builds the app and ships it to the global edge. A deploy of main goes to the canonical URL; a branch or preview deploy gets its own preview URL.

https://<slug>.cloudrizz.app

• deploy_app, build and publish.
• get_deployment_logs, read build / runtime logs if something fails.

Put the app on your own domain with add_domain. Cloudrizz returns the exact DNS record to add; SSL is issued automatically. The simplest setup is a www subdomain on any DNS provider:

www.example.com   CNAME   <slug>.cloudrizz.app

Apex domains and other providers are supported too, add_domain returns the right records for the option you choose.

Keep chatting. Each round is the same loop: edit_file → save_version → deploy_app. Clone an existing app to start from a known-good base with create_app (from: "clone"), and improve search and AI discoverability with update_seo_config.

For the complete list, see the MCP tool reference.