Guide · HTML & dashboards

How to host an HTML file or dashboard from your AI agent

Your agent built a self-contained HTML page or an interactive dashboard. It's sitting in a folder on your machine. Here's how to turn it into a real URL someone can open — interactive, private, and with no build pipeline to set up.

The short version: freo.cloud lets your AI coding agent — Claude Code, Codex, Cursor, Windsurf and more — publish an HTML file or a whole multi-file site straight to a shareable link, without you touching a hosting provider. You connect the agent once, then just say "publish this and give me the link." The page renders in a locked-down sandbox, so its JavaScript and CSS keep working — charts stay interactive, filters still filter. No repo, no bucket, no deploy step.

On a chat app like Claude.ai or ChatGPT instead of a coding agent? Connect the MCP server with one-click OAuth (no token) — then the same "just ask it to publish" flow applies.

The problem: a great page with nowhere to put it

Agents are excellent at generating a self-contained .html page, but everything after "done" is awkward: emailing the file is friction and a security smell, a screenshot throws away the interactivity, and standing up GitHub Pages or an S3 bucket is real work for one page you'll share once. A public repo or bucket is also the wrong default for numbers you'd rather not see indexed on Google.

What you actually want is boring: a URL, scoped to the people who should see it, that you can paste into Slack or an email — produced by the agent that already has the file open.

The fast way: connect once, then just ask

You wire up freo.cloud a single time. After that your agent can publish on its own, in plain English, whenever you ask.

1. 01

   Sign in with your email

   No passwords — a magic link drops you into your own @handle space, where everything you publish lives.

2. 02

   Copy your setup prompt

   From your Connect page — it's one-time and expires. Your publishing key never appears in any URL.

3. 03

   Paste it into your agent

   Your agent claims a scoped publishing key and saves the publishing skill for itself. macOS, Linux and Windows.

4. 04

   Ask it to publish the page

   No flags to remember — the skill lives on the agent now, not in your head.

One file, or a whole site

A single self-contained .html file is the simplest case — its inline CSS and JavaScript just work. But agents often produce a small bundle: an index.html plus separate .css, .js, fonts and images. You can publish the whole folder in one go — the agent uploads each file with its relative path and points the entry at index.html, so links between your assets resolve exactly as they do locally. Up to 200 files, 10 MB each.

Either way the page renders inside a sandboxed, null-origin iframe — so a charting library, a bit of vanilla JS, or a small framework build all run normally. Interactivity is the whole point; it survives.

Controlling who can open it

You pick one of four access levels when you publish — unique link, email-protected, allowlist, or public — and can change it later without changing the link. The access-control guide covers when to use each.

A link nobody opens for about a month quietly goes private on its own, and you can set a hard expiry — useful for a dashboard that shouldn't outlive the conversation it was built for.

The alternatives, fairly

freo isn't the only way to put an HTML page online, and for some jobs it isn't the right one:

• →GitHub Pages is great when the page belongs to a repo you already maintain and you're happy for it to be public. It assumes a git workflow, though — and a lot of agent output lands in a scratch directory that was never a repo.
• →Netlify / Vercel shine for a real app with a build step and a custom domain. For a single generated page, a full deploy is a lot of ceremony — and per-viewer access control isn't the default.
• →An S3 bucket works, but you own the bucket policy, the cache headers, and the "is this accidentally public?" question forever.
• →freo.cloud is the fast path for "one page, the agent makes it, a few people should see it, and I'd rather it not be on Google." If you outgrow that, the others are waiting.

Is it safe to host agent-generated HTML?

It's worth asking — agent output is code you didn't hand-write. Published pages run in a sandboxed, null-origin iframe, walled off from your account and ours, and are served with noindex and no-referrer headers so they can't leak into search or analytics. Uploads are scanned for malware and for leaked API keys before a viewer can open them, and image metadata (EXIF/GPS) is stripped on ingest. You get the URL; the blast radius stays small.

Questions