Yes, through Webflow Cloud. It is a deployment and hosting environment for full-stack applications, built to run Next.js and Astro apps on an edge runtime, deployed from GitHub. It sits alongside the visual Webflow site you already know rather than replacing it.
This is the most significant change to what Webflow is in years, and a lot of people have not registered it yet. Webflow spent a decade as the place you built the marketing site, then handed the product off to a separate stack on a separate domain. That split is what Webflow Cloud is aimed at.
We build in Webflow every day, so this matters to how we scope projects. Here is what it actually does, based on Webflow's own developer documentation, and where we think it fits.
Webflow describes it as "a deployment and hosting environment for full-stack applications." You can deploy an app on its own, or attach it to an existing Webflow site. Webflow calls the underlying platform a "fast Edge runtime", and the whole thing is driven from a GitHub repository rather than the Designer.
The important word is full-stack. This is not a way to add a bit of custom JavaScript to a Webflow page. It is a place to run server-side code, with its own storage, deployed from a repo, on infrastructure Webflow operates.
That makes Webflow two products in one account. There is the visual site builder, which publishes pages, and there is an application platform, which deploys code. They can live on the same domain, which is the part that makes this interesting.
Two, and only two. Webflow's documentation names Next.js for "full-stack applications with powerful server-side rendering" and Astro for "high-performance, content-focused websites that ship minimal JavaScript". If you work in something else, this platform is not currently for you.
We read that pairing as deliberate rather than limiting. Next.js and Astro cover the two shapes of project Webflow customers most often need, which is an application with server logic and a content site that needs to load fast.
The Astro description is the one worth reading twice. Webflow, a company whose whole business is visual site building, is describing a framework by how little JavaScript it ships. That is a company that understands why its hosted sites feel fast, and it lines up with everything we argued in our comparison of static and server-rendered websites.
Through GitHub, like any modern platform. You connect a repository, authorize the Webflow Cloud GitHub App, pick a starter template, configure the app, and deploy. After that, Webflow's docs say "future pushes to the deployed branch will start new deployments automatically."
The prerequisites are short. Webflow lists a Webflow account, a GitHub account, permission to create apps in your Webflow Workspace, and permission to install the Webflow Cloud GitHub App on the GitHub account. That is a normal set of requirements for a deploy platform.
At configuration time you choose a deployment target. Webflow's documentation describes two options: a new domain, which creates a standalone app with its own domain, or an existing site, where the app is mounted at a path such as /app.
That mounting behavior is the feature. Being able to serve an application at yoursite.com/app, on the same domain as a Webflow marketing site, removes the subdomain split that has annoyed marketing teams for years. One domain means one set of analytics, one cookie scope, and no authority spread across two hostnames.
Three types, all serverless. Webflow's documentation lists SQLite for "reliable, relational storage for structured data", a Key Value Store described as "fast, edge-cached storage for unstructured data", and Object Storage for "scalable, secure storage for files and media". Each is scoped to the environment and deploys with the app.
That set covers most of what a small application actually needs. A relational database for records, a fast key value store for sessions and caching, and somewhere to put files. It is not a replacement for a full managed Postgres, and it does not pretend to be.
Storage being deployed with the app is the notable design decision. It keeps environments genuinely separate, which is the kind of thing that sounds like a detail until the first time someone writes test data into production.
Normal Webflow hosting publishes pages you designed in the Designer. Webflow Cloud deploys code you wrote in a repository. One is a visual publishing pipeline with a CMS behind it, the other is an application runtime. They are different products that happen to share an account and can share a domain.
Practically, the CMS story does not change. If your need is a marketing site with structured content, the Webflow CMS still does that job, and the habits in our guide to Webflow CMS best practices still apply. Webflow Cloud is for the things the CMS was never meant to do.
The distinction we draw for clients is whether a page is content or behavior. Content belongs in the CMS, where a marketer can edit it without a developer. Behavior, meaning anything with logic, state, or authentication, belongs in code. Webflow Cloud is the first time both can live in one place without a compromise.
Teams who already run their marketing site on Webflow and need to ship one application next to it. A customer portal, a calculator, an onboarding flow, a small internal tool, a documentation app. Things that are too interactive for the CMS but do not justify a separate platform and a separate deployment story.
It is also for agencies and studios, which is where our interest sits. Being able to hand a client one platform, one bill, and one domain is genuinely simpler than the usual arrangement where the site lives one place and the app lives another.
It is not for teams with an existing large application on another framework. Two supported frameworks is a real constraint, and migrating a mature app to chase hosting convenience is rarely worth it.
Concentration risk, mostly. Putting your marketing site, your CMS, your application runtime, and your data storage with one vendor is convenient right up until you want to leave. Every one of those is individually replaceable today. Together they are a much bigger commitment.
We also note what the documentation does not say. The developer docs we read do not spell out plan requirements, region availability, or usage limits. For a marketing site that is a detail. For an application you intend to run a business on, those are the questions to get answered in writing before you commit, and we would ask Webflow directly rather than assume.
The third caution is maturity. This is a newer part of Webflow's product surface than the Designer or the CMS, and newer platforms change. That is not a reason to avoid it. It is a reason to build the parts you could move if you had to.
No, and that is not what it is for. If you have a Webflow site that works, leave it on Webflow hosting. Webflow Cloud is additive. It gives you somewhere to put the application you do not have yet, or the one currently living awkwardly on a subdomain.
The migration worth considering is the opposite direction. If you have a small app on a separate host and a Webflow marketing site, consolidating onto one domain has real SEO and analytics benefits, and this is now a supported way to do it.
Our general view on building custom versus building in Webflow has not changed, and we set it out in our piece on Webflow versus custom code. Webflow Cloud does not make custom code unnecessary. It makes the boundary between the two less painful.
It is Webflow admitting that its customers already had developers. Every serious Webflow site we have worked on has custom code somewhere, and most companies running one also run an application that lives somewhere else entirely. Webflow Cloud is a response to that reality rather than a change of direction.
We think the strategic read is straightforward. The value of a site builder falls as AI makes generating pages easier. The value of being the platform where a company's whole web presence runs does not fall the same way. Owning the runtime is a much stronger position than owning the editor.
If you have an app on a subdomain and a Webflow site on the main domain, this is worth a serious look, because consolidating those is the clearest win available. Deploy a starter template, mount it at a path, and see how the workflow feels before planning anything larger.
If you have no application and no plan to build one, nothing changes for you today. Keep building the site well. The platform will be more mature by the time you need it, and you will have lost nothing by waiting.
If you are weighing whether a piece of what you want belongs in the CMS, in code, or somewhere else entirely, that is a conversation we have most weeks and we are happy to have it with you. Let's talk. You can reach our team at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.