OpenTree DashboardSign in

$ sort -k2 -r hosts.tsv

Choosing private hosting for HTML an agent wrote

A roundup written by one of the entrants, which is a reason to read it sceptically. The mitigation used here: describe the shapes rather than rank the brands, name where this deployment is genuinely the weaker choice, and give you a decision rule you can apply without trusting the author.

Why private is the hard requirement

Agent-generated HTML is assembled from whatever was in the context window, which routinely includes query results, customer rows, internal metrics and occasionally the credential that fetched them. Publishing that to a public URL is not a privacy preference, it is a disclosure. Every host below can serve a file; the axis that separates them is what happens by default to a file nobody vetted.

What to look for

Seven shapes, and what each is best at

A publish primitive (this deployment)

One call in, private URL out; twelve MCP tools; replace-in-place; per-link password, email gate, one-time view, expiry and end-to-end encryption. Weakest where you want a project: no build, no runtime, no version history.

Drag-and-drop hosts

Fastest possible path from a file on your desktop to a link, and comprehensible to anyone. Aimed at a person at a browser, so automation and per-link gating are afterthoughts.

Agent-storage services

Hosting bundled with durable state for agents. Attractive when the artifact needs to remember something between runs; more product surface to adopt than a single verb.

Source-hosted pages, on a private plan

Documentation living beside the code it documents, with access tied to organisation membership. Excellent for internal docs, wrong for a link to one external reviewer.

Polished static hosts with an editor

A nice middle ground for people who want to tweak the page after publishing. The editor is the product, which means the agent is a second-class caller.

Company-gated publishing tools

Everything is visible to your company and nobody else. The right answer inside one organisation, and no answer at all when the reader is a client.

Full application platforms

Builds, functions, previews, rollbacks. Correct for products, an order of magnitude too much machinery for a page an agent wrote this afternoon.

Summary comparison

ShapePrivate by defaultAgent-callableSame URL on revisionLinks can expire
Publish primitiveYesYes — MCP + RESTYesYes, by default
Drag-and-drop hostNoPartlyUsually notRarely
Agent-storage serviceOftenYesYesVaries
Source-hosted pagesOrg plan onlyVia commitsYesNo
Static host with editorPlan featurePartlyYesVaries
Company-gated publisherWithin the companyVariesYesVaries
Application platformPlan featureYes, project-shapedYesNo

Recommendation by situation

Where this deployment is the weaker choice

Stated plainly, because a roundup that never loses is an advertisement. There is no build step, so anything needing a bundler must be built before it arrives. There is no server-side runtime for your code. There is no version history — replacing content overwrites the same object. There are no branch previews, no team roles, and no CDN configuration knobs. And it is self-hosted, which means the uptime, the quota and the upgrade are yours.

Is an unguessable URL enough on its own?

For a lot of sharing, yes — it is capability-based access control and the entropy is not the weak point. It stops being enough the moment the link gets forwarded, which is what the password, email gate and one-time options are for.

How do I test a host without committing?

Publish the same artifact to two of them and send yourself both links. The differences you care about — default privacy, whether the URL survives a revision, what the reader sees — all show up in about ten minutes.

What is the cheapest option?

Self-hosting, if you already run the platform account — this deployment is designed to sit inside a free tier. That trade buys you the operational responsibility, which is not free.

Keep reading