Publishing an app

Through your coding agent

Connect the agent to https://reachpad.dev/mcp once, which is one URL and four steps, then ask it to publish. It calls create_app and gets the link back in the answer.

• name is what your list shows.
• files is an array of { path, content }, with the content written as text rather than encoded.
• slug picks the subdomain. Leave it out and it comes from the name.
• manifest says how the version runs: { "kind": "page", "entry": "index.html" }, or { "kind": "function", "entry": "server.js" } for a server, whose env holds plain string values the module can read. Omit the manifest for a page.
• access sets who can open the link. Leave it out and it is anyone signed in to your organization.

Publishing a change

Have the agent call read_app first. It answers with the app's live version and that version's id. Pass the id to update_app as base_version_id.

If somebody else published in between, update_app refuses with stale_base rather than dropping their version. The move after that refusal is to read the app again and publish against what is live now.

A publish replaces the whole file set. A file that was in the last version and is not in this call is not in the app any more.

New versions go live as they are published, up to 60 an hour for one app.

Uploading a file

Add an app takes one file and publishes it as version 1 of a new app.

• A Markdown file is rendered to a page, and the Markdown travels with it.
• An HTML file is served as it is.
• Any other file gets a page naming it and its size, with the file itself behind that page.

The same screen writes a build prompt you can paste into a coding agent that has your project folder open, for the times when the thing you want published does not exist yet.

What the link serves after a publish

The app's own link always serves whichever version is live. Each version also keeps a link of its own that never changes what it serves: versions and their links.