Where a platform is genuinely great
Builds with a dependency graph. Server-rendered pages and API routes. Preview deployments per branch. Rollbacks with a record of what shipped when. Image optimisation, edge middleware, environment management, team roles. If you are shipping a product, that machinery is the job, and nothing here replaces any of it.
Where it is heavy
A project per artifact. Agent sessions emit documents at a rate that turns "create a project" into the dominant cost, and the residue is worse than the effort: a dashboard of dozens of projects, each with one file, none with an owner, all public. Deleting them is a chore nobody schedules.
What this does instead
- No project. One call, one URL, nothing to create first or clean up after.
- Private by default. An unguessable token, not a public hostname.
- An ending. Links expire, and the purge deletes the object.
- The same URL on every revision. Not a new deployment per change.
- An agent interface. Twelve MCP tools, so publishing is a tool call.
Use both — that is the normal answer
The product on the platform, the artifacts here. The dividing question is not which tool is better but whether the thing you are publishing has a lifecycle. If two people will change it over the next year, it wants a project. If one person will read it once this week, it wants a link.
# the artifact half, in full
npx -y opentree-mcp
# → then, from the agent: publish_html { content: "…" }For the one-off artifact case
| Application platform | OpenTree | |
|---|---|---|
| Unit | A project | A document |
| Setup | Repository, build, settings | None |
| Default visibility | Public | Unguessable and unindexed |
| Revision | A new deployment | Same URL, new bytes |
| Lifetime | Until deleted | Expires by default |
| Runtime code | Yes | No |
| Where it runs | Their platform | Your own account |
Can this replace my application platform?
No, and it should not try. No build, no runtime, no previews, no rollbacks. It replaces the habit of using one for single files.
What about a static site with a hundred pages?
A zip becomes a multi-file site, so it will host it. Whether it should is a different question: something maintained over a year usually wants a project and a build.
Can I move an artifact onto a platform later?
Yes — GET /sites/:idOrSlug/content returns the exact bytes, and there is no proprietary
wrapper around them.
Is self-hosting really cheaper?
On a free platform tier for artifact-sized traffic, generally yes. You are buying that with operational responsibility, which is a real cost even when the invoice is zero.