Publish a Folder of Files as a Website with an AI Agent

The short answer

Yes, you can point an AI agent at a folder and ask it to put the contents online. What you cannot do is send the folder as it is. Birta serves files to browsers, so something has to turn your notes, drafts and screenshots into a page, and that something is the agent.

Everything below follows from that split. Your agent reads the folder, decides what the site should contain, writes index.html and the assets beside it, and hands the result over through its Birta connection. Birta checks the package, stores it and serves it at an address. It does not build, render or convert anything on the way.

So the question is never "will Birta accept my folder." It is "what does my agent have to produce from my folder."

What has to be true before a folder can go live

Three conditions, and only three.

There has to be an index.html at the root of the folder being published. Without one, publication is refused and nothing is stored. In practice that one file is often the whole site: 70.5% of measured projects publish exactly one. The same condition trips up an archive rather than a folder, where the entry page usually sits one level down. The refusal is specific: if an index.html exists deeper in the tree, Birta names that file and tells you to move it to the root or to declare its folder as the built site. If there is none anywhere, it says to run the build and publish the folder holding the result. The build is your side of the line.

The files have to be web types. A folder of .docx and .pdf is not a website.

And the whole thing has to fit the space your plan gives one project. On the free plan that is 25 MB for the site, not per file.

Which of your files reach the site

This table is the part most people get wrong about their own folder.

Two rows deserve a second look. .txt genuinely is served, which surprises people who assume plain text behaves like Markdown. And .svg counts as text rather than an image for transfer, so it travels as-is.

The last row is quieter and useful: environment files, SSH keys, certificates and build junk are filtered out before anything transfers, so a stray .env does not travel.

What your agent actually does

The conversion is the agent's work, and so is the quality of the result. If the page looks wrong, that is a conversation with the agent rather than a hosting problem.

Given a folder of raw material, a competent agent reads what is there, proposes a shape, usually one page or a small handful, writes the HTML and CSS, resizes the photographs, because camera output blows past 25 MB long before the text does, and keeps your originals out of the published folder, so the site contains pages rather than a directory listing of drafts.

Your originals can still travel. If the agent writes the site into its own folder and declares that folder as the published one, everything outside it is kept alongside the version as source material: stored, counted against the same 25 MB, not served. Usually what you want, since the notes stay with the project without becoming pages.

Two ways the folder gets across

Which one you get is decided by your client, not by you.

If the folder is a clone of a repository, one question comes first: whether it holds a built site or sources that still need a build. Publishing from a repository starts there.

1. Step 1ConvertThe agent writes the site
2. Step 2Hand overFile by file, or folder at a time
3. Step 3FixRead the refusal, do not guess

A client that cannot read your computer's files works through the hosted connection: Claude on the web, Claude Desktop, Claude Cowork, an eligible ChatGPT workspace. The agent creates the project, opens a draft and writes it file by file. Images travel base64-encoded, which costs roughly 1.4 characters of message per byte, so a folder of unresized photos is expensive on this route. Ask for the resizing before the upload.

A client that works with files on your machine uses the local connection: Claude Code, Codex, Cursor, ChatGPT Desktop. Here the agent sends no file contents. It names the project folder and the folder holding the finished site, and the connection reads both and uploads them itself.

Both routes end the same way. You get a draft at its own address, you look at it, you leave remarks on the page if something is wrong, and the agent uploads again into the same draft. Nothing is live until a separate publish call. The full reference is on the Birta MCP page.

What to say to your agent

The prompt that works is bounded. It tells the agent what to make, where to put it, and what not to touch.

Look at the files in this folder and tell me what a small website made from them would contain. Then build it: write index.html at the root of a new folder called site/, with the CSS and images next to it. Resize any photo wider than 2000 pixels. Leave my original notes, PDFs and documents outside site/. Publish site/ to a Birta draft and give me the draft address. Do not publish it live until I say so.

Notice what it does not say. It does not name a framework, ask for a build step, or describe a deployment. Those are the parts this workflow removes.

When it does not work

Four failures cover almost everything.

The package has no start page

A refusal naming index.html. Either the agent wrote the site into a subfolder and published the wrong level, or it never wrote one. The message tells you which, because an index.html that exists somewhere is named in the refusal.

A document is missing from the live site

It was dropped as an unsupported type. Markdown, PDFs, Word documents and video all behave this way. Ask the agent to move the content into a page, or to link out to the file where it already lives.

The upload is too big

The free plan gives one project 25 MB, and the refusal states the size it measured. Images are almost always the cause. Resize before the handover, or move large originals out of the folder you publish, though they still count if they travel as source material.

The site loads but internal links break

Birta serves files. A path ending in a slash gets the index.html inside that directory, and an explicit .html path is served as itself, so an ordinary multi-page site works: /about/ and /about.html both resolve. A single-page app can be published. Its in-app navigation has to run through #: with regular paths, opening or refreshing any path other than the root returns “page not found”. A static export that writes one file per route, linked with a trailing slash, keeps those regular paths working, and search indexes each of them separately.

When the folder is not a website

Some folders should not be published here at all. If what you have needs a server you control, a database, user accounts, scheduled work or a private key that stays secret at runtime, this is the wrong home and converting changes nothing. An application belongs on an application host.

One near miss worth naming: a Notion export lands as exactly this kind of folder, pages and asset directories with no site structure, so the mechanics here apply. Whether you should export at all is the prior question, and the Notion comparison answers it before the folder exists.

The free plan covers the case this page is about: 50 projects, 25 MB each, on a birta.link address with the Birta mark in place. Your own domain starts on the $12 Solo plan. For enquiries, the free plan takes ten per site a month, they land in the project panel, and an email digest follows roughly 15 minutes after the first.

Frequently asked questions