For developers
Which way should I publish?
All five publish the same files to the same place. Pick on how you work, not on capability.
| If you… | Use | Because |
|---|---|---|
| have a folder and want it online now | Drag and drop | No token, no install. Portal → your site → Publish. |
| keep the site in a Git repo | GitHub | Connect once; every push to the chosen branch publishes. |
| already run a build | CLI | One line at the end of your build script. |
| are wiring this into your own system | HTTP API | A zip and a bearer token. No SDK to adopt. |
| want an assistant to do it | MCP | It can read the site before it replaces one, and undo itself. |
| do not have files at all | The editor | Start from a design and edit in the browser. |
They mix freely
Nothing is exclusive. A site connected to GitHub can still be published from the CLI; a site built in the editor can later be replaced by a zip. The last publish wins, whichever door it came through, and every one of them is listed in the site's Activity with the door it used.
deploy REPLACES the whole site — it is not a sync. Files you do not send stop being served. If you are publishing from an assistant, have it read the site first.One exception
A site being edited in the browser refuses a file publish. The editor holds the whole site as a document, and dropping a zip on top of it would silently throw that document away — so the API answers 409 studio_managed instead. Publish from the editor, or start a site whose files are yours to begin with.
No files at all yet? Browse the designs and start from one of those instead.