Showing a client the change before it is live

One staging subdomain per site

Webflow gives a site two publish targets: the staging subdomain at yoursite.webflow.io and your custom domains. To show work without shipping it you open the publish dialog, check the staging subdomain, uncheck the custom domain, and publish to selected domains. It works. It is also singular. There is one staging URL, so the second change in flight has nowhere to live, and whatever your colleague pushed to staging an hour ago is what your client sees when they open the link.

That URL is public. Webflow documents a separate step to stop the staging subdomain appearing in search results, which means the default is indexable, and your unreleased pricing page sits on the open web until somebody remembers. Private staging, where webflow.io and custom staging domains require a login, is restricted to Enterprise customers and partners. Everyone else is sharing an unlisted URL and hoping.

There is a smaller trap in the same settings panel. Rename the staging subdomain and Webflow replaces both the subdomain and the site's read-only link instantly, so every read-only link you have already sent stops working. Harmless on a personal project. Less harmless when four of those links are sitting in client inboxes.

Branching exists, and it is priced like a platform

Webflow does ship page branching: branch a page, edit the copy freely, merge when you are ready. The requirements line says Team and Enterprise Platform plans. On the pricing page today the cheapest Platform plan is Team at $2,500 a month with an annual contract, against $25 a month for the Premium site plan. Reviewing a change in isolation is a feature of the tier where you have a procurement process.

Read the merge semantics before you budget for it. Webflow warns that any change made to the original page's content while it was branched is lost when you merge, though components, classes and interactions survive. Comments on the branch, resolved and unresolved, are permanently deleted at merge and cannot be recovered. Content editors and marketers can create branches but not merge them. That is a reasonable set of rules, and it is still a set of rules you have to hold in your head because you cannot read a diff.

None of this makes Webflow a bad product. It makes a specific thing hard, and that thing is cheap everywhere that software is files in a repository.

A URL per version instead of a shared one

Cloudflare documents a Version URL for every version of a Worker, created whenever you run wrangler deploy or wrangler versions upload. The format is version-prefix, worker name, then your workers.dev subdomain, and wrangler versions upload --preview-alias staging gives you a readable one pinned to that upload. Two people with two in-flight changes get two URLs, because the URL belongs to the version rather than to the site. Cloudflare Access can put a login in front of them, for one Worker or every Worker in the account. The documented limits are honest about the edges: aliases are only created at upload time, the thousand most recent are retained, and you cannot read logs for a Version URL through Workers Logs, wrangler tail or Logpush.

The database half comes from Supabase branching. Each branch is its own environment with its own instance and its own API credentials, cloned from the main project with its edge functions already deployed. Preview branches are ephemeral and get deleted when the pull request is merged or closed, so nobody has to remember to clean up. They start with no data and no storage objects by default, which Supabase explains as a deliberate guard on production data, and you opt into a seed file if you want rows. On merge, the deploy workflow waits up to two minutes for Auth, API, Database, Storage and Realtime to report healthy before it applies migrations.

Supabase Pro is $25 a month and includes $10 of compute credits, which covers one Micro instance. The number worth noticing is not the price. It is that a preview is an artifact of how the stack works rather than a plan you upgrade to.

What that bought on a real migration

Stay World Class ran on Webflow and Xano when we took it over and now runs on Next.js, NestJS and Supabase. The part that mattered during cutover was a four stage ETL that preserved every legacy ID as a PostgreSQL UUID, which is what let us rehearse the migration against a copy and compare the result row by row instead of trusting it. Lighthouse went from 55.91 to 91 out of 100 and LCP came down 77%.

The reviews changed shape too. Showing someone a branch deploy and showing someone the thing you are about to ship became the same act. I had not expected that to be the part people commented on, and it is the one they did.

When one staging URL is the right amount

If one person edits the site and the client looks at finished work, the staging subdomain does everything you need and an owned stack would be a worse deal. You would be trading a publish button for migrations, a deploy pipeline and a person who keeps both running. Teams that migrate to fix a review workflow and nothing else usually end up with the same workflow and a new on-call rota.

What moves the answer is concurrency and secrecy. Two designers with separate unfinished work, or a client who needs the preview to be genuinely private rather than merely unlisted, is the point where one shared public URL becomes the constraint. If you are already coordinating in Slack about who may publish to staging this afternoon, you are doing environment management by hand. The question then is whether $2,500 a month for Platform branching is better value than owning the stack, and that is a real comparison with a defensible answer either way.