Guide

Where to put the files your AI agent makes

Your AI coding agent just built something — an HTML dashboard, a report, a PDF, a chart. It's sitting in a folder on your machine. Now someone needs to see it, and the obvious question is the awkward one: where does this thing actually go so I can send a link?

This is a surprisingly real gap. Agents like Claude Code, Codex, Cursor and Windsurf are great at making things, but the output lands as a local file with no home. You can't text someone a path on your laptop. Below is a fair look at the usual places to put that file, what each is genuinely good at, and where each falls down — so you can pick the right one for what you actually have in hand.

It depends on what you have: a public project in git suits GitHub Pages, a real app with a build step suits Netlify or Vercel, a pile of programmatic uploads suits S3. But most agent output is a single file — an HTML dashboard, a report, a PDF — you want a few people to open once, ideally off Google. The developer hosts are too much ceremony there and default to public. freo.cloud is built for that case: connect your agent once, ask it to publish, and get a private, access-controlled link back.

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 options, compared

There's no single right answer — it depends on whether you're shipping a full site or sharing one artifact, whether it's public or private, and how much setup you're willing to do.

Notice the split. The developer-grade hosts (GitHub Pages, S3, Netlify, Vercel) are built to deploy projects — and they're excellent at it. But most of what an agent hands you isn't a project; it's a single artifact you want one person, or a few people, to look at once or twice. Emailing it works until you need to change a number or see whether anyone opened it. That single-artifact, who-can-see-it gap is exactly the one freo.cloud is built for.

There's also a newer option: agent-native page features like Claude Code Artifacts and ChatGPT Sites. Both can publish publicly as of July 2026, so they're a real choice for getting a page online fast. What they don't do is the client-delivery part — no check for leaked API keys on the way out, no way to see which person opened it, no expiry, and no way to lock a link to one client who isn't in your company directory. See how freo compares to Claude Code Artifacts and ChatGPT Sites.

A worked example: report.html, two ways

Both get a URL. The difference is everything in between — and whether the result is public. If it's specifically an HTML page or dashboard, see how to host an HTML file or dashboard from your AI agent.

So which should you pick?

• →A public project you keep in git → GitHub Pages.
• →A real app with a build and a domain → Netlify / Vercel.
• →Lots of assets, uploaded programmatically → S3 + a static host.
• →One file, a few viewers, keep it off Google → freo.cloud.

How freo fits the "one file, one link" case

freo.cloud gives your agent a personal @handle space and a place to publish what it makes. You connect once by pasting a setup prompt; the agent claims a scoped key and installs the publishing skill. After that you don't manage hosting at all — you just say "publish this" and you get a shareable link back.

Access and safety, honestly

Every published document gets its own access level — public, an unguessable unique link, email-protected, or a named allowlist — so "share with the team" and "show the whole internet" never get confused (see access control for AI files).

Published HTML is sandboxed so a page can't reach into the rest of your space, uploads are run through secret scanning to catch a stray API key before it goes live, and each document carries its own view tracking. None of this is magic — it's the boring safety net you'd want before handing a link to someone outside your laptop.

Questions