Static.app alternative: choose by who maintains the site

The short answer

Static.app is not a manual-upload-only host: it has an official MCP server for compatible assistants, a REST API, a GitHub Action, dashboard file editing, and ZIP uploads and imports from a public URL. By hand, Birta takes one HTML file in Publish HTML, with no account. Both connect to an agent, and what differs is how far one connection carries the work. Stay with Static.app if your working surface is its dashboard, a repository, your own API workflow or its MCP connection. Choose Birta when a request should run through a draft, a preview, publication and recovery without you reconstructing that path on every edit.

If it needs a database, accounts or server-side code, check which of the two you have first.

Where Birta's job starts

Birta matches little of that input side: no dashboard file manager, no ZIP upload, no URL import, no GitHub Action, no document-to-HTML conversion. The one manual route is Publish HTML: paste HTML or drop a single .html file, and your browser draws the preview without sending anything until you press "Get a link to send". The link opens for anyone for 24 hours and is kept out of search; "Keep it in my account" turns it into a site with a permanent address. It takes one document up to 1 MB. Inline CSS and JavaScript run, images in a folder beside it do not travel, and a ZIP or several files are refused.

A site of several files comes from an agent. Birta's own agent in the panel builds it from what you describe or attach in its chat; Claude Code, Cursor and Codex read your folder; Claude Desktop, Cowork and ChatGPT turn a document or a public page into HTML. Birta starts where none of them reaches: an address, a record of what was published, a way back, remarks on a version, a form, a domain, a visitor count.

Static.app's connection is official and documented. The help centre documents its MCP server at mcp.static.app/sse, on an account API key and an active plan: thirteen tools, nine for sites and files, four for forms and their entries.

Those thirteen trace the dashboard. None names a draft, a version, a publish step or a rollback; the file tools write to the site itself, and the rollback the documentation does describe lives in the dashboard, past the edge of the connection.

Birta was built from the other end. Its own agent and any connected one share the same loop: copy a version into a draft, edit, publish, list what came before, restore one, read the remarks.

Send a version out for review

On Birta every version has its own address, handed over when the client opens a draft and again when it publishes. It keeps working after the site goes live, so it stays the link you send for an opinion rather than a launch.

The reviewer needs no account. Access defaults to a plain link, the guest gets a nickname, and they mark the page up in the browser: click the heading or image that is wrong, type the remark, and it pins to that element. Numbers are never reused, so "number four is still open" means the same thing next week.

The agent reads the threads with list_version_comments, changes the same draft and publishes, then replies in each thread and closes it. Everyone with project access gets one email digest roughly 15 minutes after the first remark, minus their own. No plan gates it; the versions and remarks guide is the loop in four steps. Two limits: the address belongs to the version, not the live site, and link access is a default a project can be moved off.

Static.app's side was checked across its MCP tool reference and the whole "Managing Your Websites" section: nothing documents commenting, annotation or a review pass. The closest is Previewing Your Page, the owner's own view inside the dashboard. If sign-off is part of your process, confirm the gap in your own account.

Compare the path from one edit to the live site

Suppose the request is small: change the headline, replace an image, check the result, keep a way back. Here is what the documented surfaces put between that request and the public URL.

Static.app automates plenty: its MCP updates files, its API manages files and domains, and its GitHub Action publishes after a repository change. The difference is the contract around the change. On Birta the client works on a numbered draft copied from a known version, the draft has its own preview, and it stays private until the client publishes. Static.app's documented tools update files and replace a site from an archive, so what a successful call changes is the site, and its help centre points recovery at the dashboard. That is what the documentation says rather than proof no other safety exists, so check it in your own account if the boundary matters.

Choose Static.app when

Static.app is the stronger fit when any of these describes how the site is already maintained:

• Your repository is the source of truth. The official GitHub Action uses an API key stored as a repository secret and publishes on repository events, and a failed build leaves the live site unchanged, according to Static.app's GitHub documentation.
• You want a dashboard file manager. Static.app documents upload, create, edit, rename, duplicate, remove and ZIP export. Birta gives the owner no equivalent editor.
• You are building your own automation. Its API documents website, file, directory, domain and SSL operations, a better foundation than a product whose primary path is an agent.
• Your forms are deeply Static.app-specific. The collector runs on the static-form attribute, so moving means replacing that contract, not copying HTML.
• You need richer first-party analytics. Its analytics product documents referrers, search terms, pages, devices, locations, bandwidth and export. Birta's view is narrower on purpose.

API, MCP and analytics access sit on paid plans, so check the live pricing page before deciding.

Choose Birta when

Birta is the stronger fit when the unit of work is a request to an agent, and that agent should stay responsible after launch.

• A change starts from the live version, not an old local folder. The client copies a stored version into a draft before editing.
• Preview is part of the contract. The draft has its own address while the public URL keeps serving the active version.
• Publication is an explicit step. Editing a file does not make it live.
• Recovery stays in the conversation. The agent lists stored versions and restores one; so can the owner, from the panel.
• Somebody outside the account signs the page off. Send the version address, the reviewer pins remarks with no account, the agent publishes the fix.
• The agent owns the form contract too. It declares forms and reads the leads.

That is the model in how to update a live site without starting over. It runs in Birta's chat, or through the connection guide for your tool.

The domain is the other owner boundary. Your agent publishes the site; you connect the domain in the panel and change the DNS record at your provider, and Birta verifies it. An agent does not silently move your domain.

What the edit-to-live ownership looks like

With Static.app, ownership depends on the route:

• dashboard: a person opens the file manager, changes files, saves, checks the site;
• GitHub: a person or coding tool changes the project, the repository event triggers the action, the action builds and publishes;
• MCP: a compatible assistant manages the hosted site and its files with the account's API key.

On Birta, its own agent or one connected client does the whole loop in a single working context:

1. list the project's stored versions;
2. create a draft from the version that should change;
3. read and change the files;
4. hand the owner the draft preview;
5. publish that draft;
6. restore a stored version if the change was wrong.

A GitHub workflow is the more repeatable path for a team that already reviews repository changes, and a dashboard editor is simpler for someone who wants direct control. Birta's loop earns its place when the maintainer is the agent and handing the work back to a person halfway through is the friction you want gone.

Move from Static.app without making the cutover irreversible

Migrate only after the workflow comparison points to Birta.

1. Step 1Keep Static.app liveExport the site as a ZIP and record its domain, routes, forms, redirects, and external files. Do not delete or empty the old project.
2. Step 2Publish a Birta copyHave Birta's agent or a connected one create a draft from the static files, inspect its preview, and publish to the standard Birta address. Leave DNS untouched.
3. Step 3Replace platform behaviorDeclare the Birta form, replace Static.app-specific form markup, and send a real submission. Treat old entries and analytics as history that does not move with the files.
4. Step 4Test before DNSCheck routes, assets, navigation, forms, visitor counting, one ordinary update, and a version restore on the standard Birta address.
5. Step 5Move the owned domainAdd the domain in Birta, use the exact record shown in the panel, change it at the DNS provider, and verify it only after the copy passes.
6. Step 6Keep the rollbackLeave the Static.app project intact while DNS settles. If a blocker appears, restore the previous DNS record and allow caches to update.

The reversible part is the domain you own. A provider address ending in static.domains belongs to Static.app and cannot be carried over, so the old project can keep opening there while your owned domain points elsewhere. That is why keeping it intact beats deleting first.

For the DNS mechanics and the usual reasons verification fails, use the custom-domain guide, and always copy the current record from the panel rather than an IP address from an article.

Decide from the second update, not the first upload

The first publication is the easy demo on both. The better test is the next ordinary request:

• Who receives "change this headline"?
• Does that person or agent have the current files?
• Is there a private preview before the public URL changes?
• Who presses or calls the final publish action?
• How is a bad update restored?
• Who owns form changes and reads the leads?
• Are daily visitor totals enough, or do you need source and page reports?
• Does the custom domain stay an owner-controlled step?

Answers pointing at a repository, a dashboard, a custom API or richer analytics mean keep Static.app. Answers pointing at an agent carrying the work from request through preview, publication and recovery mean Birta is worth testing.

If you never reach the second update because the site was a one-off share, the comparison you want is Netlify Drop: it starts at the first click and stops where this page begins.

Frequently asked questions