Webstudio — an open source Webflow alternative, and the two meanings of self-host

• Webstudio

  This page

  PricingWebstudio leads

  • A free cloud tier, which comes with a subdomain rather than a custom domain
  • Paid cloud tiers are per-site subscriptions and scale by hosted page views, with usage beyond the included allowance charged as overages
  • Self-hosting the sites you build costs nothing to the vendor at all, which is the escape from metering entirely
  • The core is free software under a copyleft licence; there is no fee to run it yourself

• Webflow

  PricingWebstudio leads

  • A free tier for building, largely for learning and staging rather than for a live brand
  • Paid hosting plans per site, with pricing driven by traffic and by the content features enabled
  • Costs rise with the number of sites, which is what an agency notices first
  • Exporting means leaving the hosting plan, so the platform and the bill are the same decision

• Framer

  PricingWebstudio leads

  • A free tier that is genuinely usable for a personal or portfolio site
  • Paid tiers are per-site subscriptions that add a custom domain, more pages and more traffic
  • Pricing is simple and site-oriented, which suits one-off marketing pages better than managing many
  • No self-hosting route, so the subscription and the site are inseparable

• WordPress

  PricingWebstudio leads

  • The software itself is free and can be run anywhere, including on very cheap hosting
  • The real costs sit around it: hosting, a domain, premium plugins and themes, and your time on maintenance
  • Paid managed hosting buys you someone else doing the updates, which is often the sensible choice
  • Plugin and theme licensing is per-site and renewable, so the total tends to accumulate rather than being visible in one line

1. Webstudio — official site
2. Webstudio — pricing
3. Webstudio — documentation
4. Webstudio — self-hosting documentation
5. Webstudio — source repository
6. Webflow — official site
7. Framer — official site
8. WordPress — official site

Free tier

Yes

Pricing summary

The structure here is genuinely two products sharing one interface, and the choice between them is the actual pricing decision. On the hosted side there is a free tier you can build a site on, with the specific limitation that it publishes to a subdomain rather than your own domain — so it is fine for a personal project, a prototype or a draft, and not a substitute for a real brand address. Paid cloud tiers are per-site subscriptions that add the custom domain, more included page views and the features that matter to a client build such as staging, backups and a content mode for handing work over. Because the cloud is metered by page views, the hosting cost tracks your traffic rather than being a flat fee, with usage past the included allowance charged as overage. On the other side, deploying the sites you build costs nothing to the vendor at all: you can export a static build or run it as a dynamic front end, and put it on your own server or any provider. For a site with real traffic, that is the difference between a metered bill and a fixed one, and it is the whole reason the self-hosting story here is more than marketing. Two things are worth understanding before you commit to a plan. The first is that hosting the *output* and hosting the *builder* are separate questions, and the project takes different positions on them — deploying sites anywhere is supported and encouraged, while running the builder itself in production is explicitly not recommended, and some capabilities remain exclusive to the cloud. The second is that "free" applies to the software, not to every component: the core is copyleft-licensed, but the animation package carries its own proprietary end-user licence. Tier names, included page views and overage rates all move, so confirm the current numbers on the official pricing page rather than planning around a figure from a review.

Reviewed on 19 September 2026 · Webstudio — pricing

• Real CSS rather than a renamed abstraction

  The style panel exposes actual properties, units and breakpoints rather than designer-friendly synonyms. That is the defining choice of the product: what you learn using it transfers directly to writing CSS by hand, and equally, what you already know about CSS applies the moment you open it. The cost is that there is more surface to understand than a tool that hides the machinery — the trade is precision and portability in exchange for a gentler first hour.

• Design tokens instead of combo classes

  Reusable styles and tokens handle consistency, which is the job that the widely disliked combo-class pattern does in the incumbent tool this product positions against. Tokens can be added, reordered and removed, and one-off changes do not require naming anything. Anyone who has maintained a large site built on stacked classes will recognise this as the specific improvement it is meant to be.

• Content from any headless CMS or database

  The builder is deliberately only the front end, and content is fetched over HTTP from whatever you already use — a headless CMS, a database, an API. That keeps the content portable and avoids the pattern where your pages are locked inside the same product that renders them. For a client site it also means the editorial team can work in a tool they already know rather than inside the builder.

• Deploy anywhere, including your own infrastructure

  Sites can be exported as a static build or run as a dynamic front end, and deployed through a CLI, with Docker, on a platform like Vercel, Netlify or Cloudflare Pages, or on your own server. There is no hosting obligation attached to having built the site, which is the concrete meaning of the no-lock-in claim — and it is why a high-traffic site can be moved off metered hosting without rebuilding anything.

• An output a developer can take over

  What is published is standard modern front-end code rather than a proprietary artefact. A developer who has never used the builder can read it, and the handover from designer to engineer does not involve a conversion step or a rewrite. For agencies and small product teams that is often the deciding factor, because it removes the fear of building on something that cannot be maintained by anyone else.

• Core under a copyleft open-source licence

  The functionality in the main repository is free software under a strong copyleft licence, so the platform can be inspected, forked and run by anyone. The qualification matters as much as the headline: the licence covers the core rather than every package shipped with the product, and at least one optional component — the animation SDK — is proprietary and governed by a separate end-user agreement. Anyone evaluating this for licensing reasons should check which parts they actually need.

• Self-hosting documentation, with honest boundaries

  The project documents self-hosting openly and encourages deploying the sites you build yourself. It is equally direct that running the builder itself in production is not recommended, and that some capabilities remain cloud-only — email sending among them. That candour is useful: it means the distinction between hosting the output and hosting the platform is documented rather than discovered, and you can decide which one you actually wanted.

• A marketplace and a component model

  There is a marketplace of prebuilt components and integrations, and a documented way to build and share your own, along with an Inception framework for building on the platform and integration with standard component libraries. It is the pressure valve against the abstraction cost — where the tool deliberately gives you fewer built-in flourishes, the ecosystem is where you go looking for them.

1. 1

   Decide who owns the output before you compare features

   Feature lists in this category have converged to the point of being uninformative. The question that actually separates the tools is what you are holding when the project ends — a site in a vendor’s hosting, a design in a proprietary format, or a codebase you can move. Answering that first immediately eliminates most of the field, and it is far cheaper than discovering the answer during a migration.

2. 2

   Test the exit path on day one, not in year three

   Whatever you choose, take one page through the full export and deploy process before you build the whole site on it. The point is not to leave; it is to know what leaving would cost while you can still make a different decision. With this product that check is straightforward — export the build, put it somewhere else, and confirm it works — and doing it early converts a marketing claim into something you have verified yourself.

3. 3

   Separate hosting the site from hosting the tool

   This is the distinction most likely to be misread, both here and in the category generally. Deploying your site to your own infrastructure is a different question from running the builder itself on your own servers, and a product can support the first enthusiastically while not recommending the second in production. If the plan behind your evaluation was to run everything in-house, find out which parts that actually applies to before you commit.

4. 4

   Check the licence package by package, not by the badge

   An open-source label on a product describes the licence of its core repository, which is not the same as every dependency and optional package being open. Here the core is copyleft while the animation components are proprietary under a separate agreement. If you are evaluating because of licensing — for a procurement review, a fork, or a compliance requirement — read the individual package licences rather than the headline.

5. 5

   Budget the abstraction cost honestly against your team

   A builder that exposes real CSS is faster for anyone who already understands CSS and slower for anyone who does not, and both effects are large. Be honest about who will actually be doing the work. The reward for the steeper path is that the skills and the output both transfer; the penalty for choosing it with a team that wanted decisions made for them is that the project stalls.

6. 6

   Plan the content layer before the design layer

   Because this class of tool deliberately leaves content to a headless CMS or database, the integration is a decision rather than a default, and it is much easier to make before the pages exist. Decide where the text lives, how editors will reach it, and what happens to a page when its content changes, then build the design around that. Doing it in the other order is how a site ends up with its content baked into the layout.

• Developers who want visual editing without a proprietary format

  The clearest fit: someone who can write CSS and does not want to, but who refuses to have the output trapped in a tool they cannot leave. Because the panel speaks the properties you already know and the build is a standard front end, the mental model matches theirs. It is the shortest path from visual editing to something that looks like code you would have written.

• Agencies with a handover problem

  Building a client site is only half the job; the other half is what happens when the client, or another agency, takes it over. A codebase that any competent front-end developer can read removes the hostage situation that hosted builders create, and the deploy-anywhere story means the client is not tied to your account. For an agency that competes on trust rather than on retention, that is a selling point rather than a sacrifice.

• Teams that already have a content backend

  If your organisation already runs a headless CMS, a database or an internal API, this fits underneath it as a front end rather than demanding to own the content. That is a materially different proposition from a platform where the CMS and the builder are the same product, and it means an editorial team keeps the tools and the workflow they already know.

• Sites where traffic makes metered hosting expensive

  Page-view metering is comfortable on a brochure site and painful on a site that goes viral or runs a campaign. Because the output can be deployed to infrastructure you control, the hosting cost stops tracking the vendor’s price list — which for a content-heavy site with unpredictable spikes is often the strongest financial argument for choosing this over a hosted equivalent.

• Anyone under a procurement or compliance constraint

  Self-hosted deployment, an inspectable core and no third party in the production request path are the specific properties that get a tool through a security review or a data-protection assessment. Combined with a copyleft licence that permits forking, it is one of the few options in this category that can be defended to a committee rather than being taken on trust.

• Designers who are willing to learn the real vocabulary

  This is a conditional fit but an important one. A designer who wants to grow towards front-end competence will find that the awkward part of learning this tool is also the part that makes them better, because nothing has been renamed to hide the mechanics. A designer who wants the tool to absorb the complexity should choose a design-led builder instead, and that is a legitimate preference rather than a failing.

The core is copyleft, and not every package is open source

The functionality in the main repository is licensed under a strong copyleft open-source licence, which means it can be inspected, modified, forked and run, with the usual copyleft conditions applying to distribution and to serving a modified version over a network. However, the product as distributed includes at least one proprietary package — the animation SDK — governed by its own end-user licence agreement. Anyone whose interest in the platform is licensing-driven should read the individual package licences rather than treating the open-source badge as covering everything.

Self-hosting the sites is supported; self-hosting the builder is not recommended

This is the distinction most likely to be misread. Deploying the sites you build anywhere you like — a static export, a dynamic front end, via CLI, Docker, a hosting platform or your own server — is a headline feature and fully supported. Running the builder itself in production is possible but the project advises against it, and certain capabilities such as sending email remain cloud-only. If your evaluation assumed a single self-hosted install replacing the hosted product, the documentation is worth reading before that assumption hardens.

Real CSS is the design decision, with real consequences

The builder exposes genuine CSS properties, units and breakpoints, and uses design tokens rather than stacked classes for reuse. The benefit is that skills and output both transfer out of the tool. The cost is a steeper surface than a builder that renames concepts for designers — which is why designers arriving from a design-led tool report the largest adjustment, and why developers tend to find it quicker than they expect.

Content is deliberately external

The platform is positioned as the front end only, with content fetched over HTTP from a headless CMS, a database or an API of your choosing. There is no built-in content store competing with those systems, which is what keeps the content portable and lets an editorial team use tools they already know. It also means the content integration is a decision you have to make rather than a default you inherit.

The free cloud tier publishes to a subdomain

A free cloud site uses a provider subdomain rather than your own domain, so a custom domain is a paid feature. That is a reasonable line but an important one: the free tier is a legitimate place to build and evaluate, and not a way to launch a brand address at no cost. Self-hosting the exported site on your own domain is the other route, and it does not involve the vendor’s cloud tiers at all.

What it does not do

It is not an application platform: complex client state, authentication and server logic belong elsewhere, and this renders the front end rather than replacing a backend framework. It is not the strongest choice when rich prebuilt interactions and effects are the priority, where a design-led tool is further ahead. It does not provide deep in-builder editorial workflow for a large content team. It does not offer an entirely open-source distribution, and it does not recommend running the builder itself in production.