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 that lets compatible assistants manage sites, files, and form entries, plus a REST API, a GitHub Action, dashboard file editing, ZIP uploads and imports from a public URL.

Both ends connect to an agent. How far one connection carries the work is what differs, and that comes down to who should own the next update.

Choose Static.app if your operating surface is its dashboard, a GitHub repository, a custom API workflow, or its own MCP connection. Choose Birta when a supported agent or chat should take a request through a stored draft, a preview, publication, and recovery without making you reconstruct that process for every edit.

If the thing you are publishing needs a database, user accounts, or server-side code, neither side of this comparison settles your hosting choice. First check whether you have a static site or an application in the vibe deployment guide.

Where Birta's job starts

Look down the list of ways content gets into Static.app and Birta matches almost none of it. There is no dashboard file manager here, no ZIP upload, no field for importing a page from a public URL, no GitHub Action. Birta does not read a folder off your disk and does not convert a document into HTML, and none of that is planned.

That is the design rather than a shortfall, because the input side is already covered by the thing you are talking to. Claude Code, Cursor and Codex read your project folder. Claude Desktop, Claude Cowork and ChatGPT fetch a document or a public page from a link and hand back HTML. A ZIP on your desktop, a page at a URL, a folder half-built by another tool: your agent gets all three into shape without a host being involved. Birta starts at the point none of them reaches on its own, which is a real address, a record of what was published, a way back to it, remarks on a version, a declared lead form, a domain, and a visitor count.

Static.app's connection is official and properly documented, so start with what it reaches once the files exist. The help centre documents its MCP server at mcp.static.app/sse, authenticated with an account API key and requiring an active plan. Its tools come in two groups: nine for sites and files, which list sites, read one, list its files, delete a site, create or update a site from an archive, download the archive, download individual files and upload files; and four for forms, which list forms, read one, read its entries and delete an entry.

Those thirteen tools trace Static.app's own dashboard. Read on 6 September 2026, none of them names a draft, a version, a publish step, a deploy history or a rollback. The file tools write to the site itself, and the rollback its documentation does describe lives in the dashboard, past the edge of the connection.

Birta was built from the other end. Its connection is the primary way the product is used rather than an extra route onto a panel, so the whole loop sits inside it: copy a stored version into a draft, edit that, publish it as a new version, list what was published before, restore one, read the remarks left on a version.

Send a version out for review

There is a step between "the change is made" and "the change is live" that neither product's feature list usually names, and it decides a lot of client work. Somebody has to look at the page and say what is wrong with it.

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

The reviewer needs no account. Version access defaults to a plain link, so a guest opening the address passes a signed handoff in the background and is issued a nickname to sign remarks with. Resolving a thread is restricted to a project member and enforced on the server.

They mark the page up in the browser. Click the heading, the image or the paragraph that is wrong, type the remark, and it pins to that element. A thread returns its number, the page and element it sits on, whether it is still open, and each message with its author and time. Numbers are never reused, so "number four is still open" means the same thing next week.

The connected client reads the threads with list_version_comments, changes the same draft, and publishes a new version. It reads only: posting a reply or closing a thread is refused, so the reviewer keeps the last word. Everyone with project access also gets one email digest of new remarks, roughly 15 minutes after the first one lands, with their own remarks stripped out. No plan gates any of it, so it works on the free tier, and the versions and remarks guide is the whole loop in four steps.

Two honest limits. The address belongs to the version, not to the live site, and link access is a default a project can be moved off.

Static.app's side of this row was checked rather than assumed, on 6 September 2026, across its MCP tool reference and the whole "Managing Your Websites" section of its help centre. Nothing there documents commenting, annotation or a review pass on a page. Neither does the tool reference, and the only rollback Static.app documents anywhere is the deployment history its GitHub Action page points to in the dashboard. The closest article is Previewing Your Page, which shows the owner the page as a visitor would see it inside the dashboard. It says nothing about a link a reviewer could open, an account-free visitor, or a way to leave a note on what they saw. If review sign-off is part of your process, that gap is worth confirming in your own account before you decide either way.

Compare the path from one edit to the live site

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

Static.app does not make a person do everything, and nothing above should read that way. Its MCP can update files, its API can manage individual files and domains, and its GitHub Action can build and publish after a repository change.

The difference is the contract around the change. On Birta's released online connection, the client works on a numbered draft copied from a known version. The draft has its own preview and does not become public until the client publishes it. That is useful when the conversation is the working surface and “make the headline shorter” should remain the agent's job through verification, not stop at a folder for the owner to upload.

Static.app's documented MCP tools update files and replace a site from an archive, and none of them names a draft, a preview or a publish step, so what a successful call changes is the site. Its help centre points recovery at the dashboard instead. That is what the public documentation says rather than proof that no other safety exists in the product, so if the boundary matters to you, check it in your own account before moving either way.

Choose Static.app when

Static.app is the stronger fit when any of these describe the way the site is already maintained:

• Your repository is the source of truth. The official GitHub Action uses a Static.app API key stored as a repository secret and can build and publish on repository events. A failed build leaves the current 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 operations for hosted files. Birta does not offer the owner an equivalent dashboard code editor.
• You are building your own automation. Static.app's API documents website, file, directory, domain, and SSL operations. That is a better foundation for a bespoke workflow than a product whose primary path is a connected agent.
• Your current forms are deeply Static.app-specific. Its form collector is activated with the static-form attribute, and its MCP can inspect form entries. Moving means replacing that contract, not merely copying the HTML.
• You need richer first-party analytics. Static.app currently documents referrers, search terms, pages, devices, locations, bandwidth, and export in its analytics product. Birta's built-in view is intentionally narrower.

Static.app's current product pages place API/MCP and analytics access on paid plans. Check the live pricing page before deciding; this comparison deliberately avoids copying prices and limits that can change.

Choose Birta when

Birta is the stronger fit when the ongoing unit of work is a request to an agent or chat, and you want that connected tool to remain responsible for the site after the first launch.

• A change should begin from the live version, not an old local folder. The connected client can copy a stored version into a draft before editing it.
• Preview is part of the update contract. The draft has a preview address, while the public URL continues to serve the active version.
• Publication should be an explicit final step. Editing a file does not make it live. The connected client publishes the draft after it has been checked.
• Recovery should stay in the same conversation. A connected client can list stored versions and restore one, and the owner can do the same from the panel.
• Somebody outside the account has to sign the page off. Send the version's address, and the reviewer opens it with no account and pins remarks to the elements they mean. The connected client reads the threads and publishes the fix, and closing one stays with a project member.
• The agent should manage the form contract too. The connected client can declare forms and read captured leads, so the form's accepted fields can be handled alongside the files that render it.

This is the same update model described in more detail in how to update a live site without starting over. It is a model, not a promise that every tool exposes the same Birta commands. Use the current connection guide for your tool and verify the operations it actually shows before choosing on this basis.

The domain is another intentional owner boundary, and it is behind the paywall. Birta's free tier connects no custom domain at all and publishes only at the standard project address; the first domain arrives on Solo at $12 a month, with five on Pro at $39. Once you are on a paid plan, your agent can prepare and publish the site, but you connect the domain in Birta's panel and change the DNS record at the provider that controls it. Birta then verifies the record and configures the secure connection. An agent does not silently move your domain.

What the edit-to-live ownership looks like

With Static.app, ownership depends on the route you select:

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

With Birta's released online route, a supported connected client can perform the content loop in one working context:

1. list the project's stored versions;
2. create a draft from the version that should be changed;
3. read and change the relevant files;
4. give the owner the draft preview to inspect;
5. publish that draft;
6. restore a stored version if the published change is wrong.

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

Move from Static.app without making the cutover irreversible

Migration is a supporting task on this page, not a reason to move by itself. Do it 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 a supported connected client 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 to Birta. Your Static.app project can continue to open on that provider address while your owned domain points elsewhere, which is why keeping the old project intact is a safer rollback than deleting first.

For the DNS mechanics and the common reasons verification fails, use the custom-domain guide. Always copy the current record from the product 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 products. 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 resulting leads?
• Are daily visitor totals enough, or do you need source and page reports?
• Does the custom domain remain an owner-controlled step?

If the honest answers point to a repository, dashboard, custom API, or richer analytics, keep Static.app. If they point to a supported agent or chat carrying the work from request through preview, publication, and recovery, Birta is the alternative worth testing.

If you never get as far as the second update because the site was only ever a one-off share, the comparison you want is Netlify Drop instead. That one starts at the first click and stops where this page begins.

Frequently asked questions