The short answer
EdgeOne Pages, from Tencent Cloud and also known as EdgeOne Makers, is not really a static-site host anymore. Its own pitch is web apps and AI agents, with Cloud Functions, Edge Functions, AI agents with built-in models, and Blob and KV storage, all on a free tier the company says stays free permanently. A much bigger product than Birta.
Birta stays narrow on purpose, and the narrow part goes deep. Its own agent in the panel, or the agent you already use once connected, reaches the draft, the published version at its own address, the rollback, the lead form and the remarks a reviewer pinned to the page. On EdgeOne those live in the console, where preview branches are switched on per project.
Backend functions, a database or an AI-agent runtime: EdgeOne is doing something Birta does not attempt. A static site with a real form and a round of feedback on it: Birta is the more focused tool.
No Git connection, and no importer
EdgeOne Pages takes your project in through its own front door: a Git repository it builds for you, its Copilot flow, or a deploy from AI output. Birta has none of that, and none of it is planned.
That reads like a gap until you notice who stands between you and the files. Claude Code, Cursor, Codex and Claude Cowork already read your working directory, run your build, and fetch a page or document from a URL. Duplicating that inside a publishing service adds a second way to do something you have.
So Birta picks up the finished output. Its side of the line is the address, the version history with rollback, remarks on a version, a declared lead form, a domain and a daily visitor count. The build stays with the agent, which is why there is nothing here to configure: no framework detection, no build command, no deploy hooks.
Blunt about the other direction too. 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”. Birta serves the stored file at a path
and nothing else, so an ordinary multi-page static site is served as its files are
stored: /about/ gets about/index.html, and /about.html gets itself.
Compare scope and the work after publish
| Decision | EdgeOne Pages | Birta |
|---|---|---|
| Best fit | Full-stack web apps and AI agents on Tencent's edge network | A static commercial site an agent builds and maintains |
| Building the site | Deploy from Git or AI, build with its own Copilot | Birta's agent in the panel or a connected one produces the site; there is no visual canvas |
| Free tier | Functions, AI agents, Blob/KV storage, and no self-serve paid tier yet | Own domain, lead form, remarks, versions and rollback; a Birta mark in the corner that the Team plan removes |
| Custom domain | Free, through the console and a CNAME record | Free, connected on the Free plan |
| Versions and rollback | Not documented as a product feature | Every successful publish is a saved version; the last 10 stay visible, and any of them can go live again |
| Lead form | No native form product found; build one with Functions | The agent declares the form's fields directly; submissions show up in the project's Forms tab, with a dashboard and email digest |
| Reviewing before it goes live | Preview deployments per branch, shared as a URL; no commenting or annotation documented inside the preview | Every version has its own permanent address; whoever holds it marks remarks on the element itself with no account, and the agent reads them back as numbered threads |
| Backend | Cloud Functions, Edge Functions, KV/Blob storage | None. Birta only publishes static files |
| Single-page app with client-side routing | Supported, with functions and path rewriting available | 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”. An ordinary multi-page static site is served as its files are stored |
| Payments from your visitors | Buildable yourself with Functions | Not yet. A planned backend module, not a permanent no |
The domain row is a tie: both connect a custom domain for free. The free-tier row goes to EdgeOne on breadth, since functions and storage come with it. What Birta's Free plan carries in full is the publishing side, drafts, versions, rollback, the lead form and the whole review round.
The Free plan is still $0 a month, and EdgeOne still answers the question directly with "Yes, our Free plan is here to stay and will be available permanently!" There is no self-serve paid tier; a Business plan exists by contacting sales, and until more options arrive "Before the paid version launches, your service will not be interrupted even if you exceed the free tier limits." Worth checking yourself before a decision rests on it.
If a project's acceleration region includes the Chinese mainland, EdgeOne requires the domain to complete ICP registration, a government process, before it can go live.
Sending a version out for review
EdgeOne Pages has the sharing half. Turn preview branches on in a project's Git settings and every push to a configured branch builds its own preview, which the docs describe as URLs you share "with team members, designers, or product managers for quick feedback collection." Birta has no branch-based equivalent, because a Birta version comes from a publish rather than a push.
What EdgeOne's documentation does not describe is anywhere for the feedback to land. We read its preview-deployment and deployment docs and found no commenting, annotation or review tool inside the preview. That is absence of evidence rather than proof, and EdgeOne's documentation set is large, so treat it as "not documented." In practice the remarks come back to you in chat.
Birta puts them on the page. Every version, draft or published, has its own permanent address, handed to the agent when it opens the draft and again when it publishes. You send that address and nothing else: whoever holds it opens the page without signing in, gets a nickname, and marks the page itself, clicking the heading, the price or the broken button so the remark pins to that element on that version.
The agent that published, Birta's own or yours, reads them back. Each thread comes with its number, the element it points at, whether it is open, and every message with author and time. Numbers are permanent, so "number four is still open" names one remark next week. The agent makes the change in the same draft, publishes, and the reviewer refreshes the tab they had open.
Then it replies in the thread and closes it with a note on what changed. Remarks also arrive by mail, one digest roughly 15 minutes after the first, minus your own. No plan gates any of it, and the versions and remarks guide is the walkthrough.
The distinction worth carrying away: a preview URL is a place to look, a version address is a place to reply, with the reply landing somewhere the agent can read. If the site only needs somewhere to look, EdgeOne's preview does that well.
Where EdgeOne Pages wins
Win on breadth. Cloud Functions and Edge Functions run real backend code without you configuring servers. Blob and KV storage give a data layer Birta does not have. AI agents with built-in models are part of the free tier.
Win on price for that breadth: a free tier including functions and storage, with a company statement that it stays free permanently, is a strong offer for a developer who needs more than a static page.
Where Birta fits better
Birta fits when the job really is a static commercial site and what is needed is publishing it, keeping a version history, and handling leads without writing backend code.
Choose it when a bad update must be reversible without rebuilding from memory. Every publish becomes a version, the last 10 stay available, and any goes live again with the original files. EdgeOne documents no equivalent.
Choose it when a real lead form belongs on the site and you want it handled without wiring up a Function. The agent declares the fields and every submission lands in the panel with an email digest behind it. EdgeOne has the building blocks through Functions, not a declared form contract.
The tradeoff is real: no backend functions, no database, no AI-agent runtime, no payments yet. What the narrower product spends its depth on is the part after the publish, and all of it sits with one agent.
Moving a static site over
This only makes sense if the EdgeOne project is genuinely static. If Functions, KV or Blob storage hold anything the page depends on, that logic has to be rebuilt elsewhere first.
- Step 1Confirm the project is staticCheck whether the site depends on Cloud Functions, Edge Functions, or KV/Blob storage. If it does, that logic has to move somewhere else, not to Birta.
- Step 2Recover the static filesPull the HTML, CSS, JavaScript, and assets that make up the actual page.
- Step 3Publish and verifyPublish through Birta, check every page and the form submission, then move an owned domain's DNS once the new site passes review.
If the answer to the first step is "yes, it depends on Functions," this is not a Birta migration.
The decision
EdgeOne Pages is the right call for a full-stack web app or an AI agent that needs backend functions and storage right now. Birta is the better fit when the job is a static commercial site and you want it published with real version history and a working lead form, without operating backend infrastructure.
Publish the static site with a form
Describe it in Birta's chat and its agent builds and publishes it. Or connect the agent you already use.