Vaadin Flow: the server side Java framework behind Vaadin's components
Vaadin Flow is a Java framework binding Vaadin web components to Java. This is part of Vaadin 10+.
At a glance
- What is it?
- Vaadin Flow is the Java framework of the Vaadin Platform, the part that binds server rendered web components to Java code and runs on the JVM rather than in the browser. This repository is a large multi-module Maven build rather than a small library, and the version table at the top is the most useful thing in it, because it shows how the framework is tied to platform releases, Java versions and Jakarta EE generations.
- Who is it for?
- Adopt Vaadin Flow if you want to build a server rendered Java web application without writing client side JavaScript, and if you are on a version line that matches your runtime, since the branch table makes the Java, Jakarta EE and Spring Boot requirements explicit per line.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Flow is, and where it sits in the Vaadin Platform
Vaadin Flow is the Java framework of the Vaadin Platform for building modern websites, and the repository description puts the mechanism plainly: it is a Java framework binding Vaadin web components to Java, and it is part of Vaadin 10 and later.
That single design decision is the whole reason to look at it. The web components that draw the interface live in the browser, but the code that decides what they show is Java, compiled and running on the server. You write a Java class, the framework turns it into a component tree, sends that to the browser, and sends events back. There is no JavaScript build step in the middle, and no separate front-end codebase to keep in step.
The repository is the framework source itself, not an example application, and the platform around it is large. The top level of the repository shows roughly thirty modules, and their names describe the architecture. flow-server/ and flow-client/ are the two halves of the protocol between the JVM and the browser. flow-data/ handles data binding. flow-push/ is the mechanism for pushing state to the browser. flow-dnd/ is drag and drop. flow-react/ is a React integration layer, and flow-html-components/ plus flow-polymer-template/, flow-polymer2lit/ and flow-lit-template/ are the component and template layers.
There are also several runtime integration modules, vaadin-spring/, vaadin-quarkus/ and vaadin-cdi/, which tells you that the framework is not tied to one application server or one dependency injection model. And there is a devtooling side, with flow-devloop-daemon/, vaadin-dev-server/, flow-server-production-mode/ and flow-webpush/.
So the scale is the first thing to understand. This is a framework with a build of its own, not a dependency you drop in.
The branch table is the real documentation, because the version lines are not interchangeable
Since Vaadin platform 23.0, Flow major and minor versions are aligned with platform versions, and the table at the top of the repository spells out what each line requires. This is the most practically important thing in the repository, because choosing a Flow version is choosing a Java version, a Jakarta EE generation, a Spring Boot version and a support commitment, all at once.
The 2.13 branch pairs with platform 14.14, described as the latest commercial release with Java 8+ support and Servlet 3. The 23.6 branch pairs with platform 23.6, the latest commercial release with Java 11+ support and Servlet 3. The 24.4 and 24.7 branches pair with their matching platform versions and are commercially supported, requiring Java 17+, Jakarta EE 10 and Spring Boot 3. The 24.10 branch is the latest 24 minor release with the same requirements.
Then the 25.x lines move the floor again. 25.2 is the latest release, requiring Java 21+, Jakarta EE 11 and Spring Boot 4. 25.3 is a Vaadin 25.3 pre-release with the same requirements, and main is described as Vaadin 25.4 preparations with those requirements too.
Read that last row carefully. main is not a stable branch, it is where the next version is being prepared, and the three release lines it sits above, 25.2 stable, 25.3 pre-release and 25.4 in preparation, tell you how much movement there is in the 25 line at any given moment.
The alignment with platform versions is a deliberate policy, and it has an obvious cost. You cannot upgrade Flow independently of the platform, and you cannot be on the newest Flow with an old Java, which rules out a lot of long-lived enterprise estates that are still on Java 8 or Java 11. For those, the 2.13 and 23.6 lines are the ones that still work, and they are described as the latest commercial releases supporting those runtimes.
The repository layout is a multi-module Maven build with a lot of history in it
The top level tells you how the build is organised and how old the project is.
There is a root pom.xml, so this is a Maven reactor, and a flow-bom/ directory for the bill of versions, which is how a project this size keeps its internal versions consistent. flow-build-tools/ holds shared build configuration. The .mvn/ directory carries Maven wrapper or settings configuration, and .tool-versions pins tool versions for developers using asdf or similar.
The presence of both flow-polymer-template/ and flow-polymer2lit/ and flow-lit-template/ is a fossil record. Polymer was the web component template Vaadin used for years, and the lit templates replaced it, with a compatibility path between the two. The same pattern shows in the tooling: there is a .prettierrc and a .husky/ directory for git hooks, checkstyle/ for Java style rules, and eclipse/ and .settings/ for Eclipse IDE configuration.
Then there is the release and governance side. A .lift.toml file configures Lift, the release tool that writes the changelog and prepares the version, which is a common choice in the Vaadin ecosystem. There is a CHANGELOG.md, a CONTRIBUTING.md, a CONVENTIONS.md describing the code conventions, and a CLAUDE.md. There is also a guidelines/ directory, which is where the design guidelines for the framework and its components live.
A .dtrack.yml file configures dependency tracking, which is a mechanism for tracking the versions of third-party dependencies across the whole platform, and it matters for a framework that spans many modules.
The .claude/ directory and the CLAUDE.md are worth a note. They indicate that the project has been set up for AI-assisted contribution tooling, which is a growing signal about how actively a project is maintained.
Push, not poll: why the transport is the interesting part
The module names hint at the mechanism, and it is the piece that distinguishes a server driven framework from a server rendered one.
flow-push/ is there because when a server-side event changes state, the server has to tell the browser, and a naive implementation makes the browser ask. The client/ directory and the push module are the two ends of that channel. flow-webpush/ sits alongside it for the same reason, and the presence of a production-mode module in flow-server-production-mode/ suggests the development and production transports are configured differently.
The practical consequence for a developer is that state lives on the server. A component holds its state in a Java field, the framework tracks the changes, and it sends the difference to the browser. That is what makes the framework server driven in the strict sense, and it is also what makes a Vaadin application need a session and a server that stays up while the user is on the page.
The other client-side modules explain the rest of the platform. flow-react/ exists because the web components are React-based under the hood, and flow-dnd/ handles drag and drop with the same server round trip. flow-data/ is the data binding layer, which is the part that decides how a Java object becomes a table and how an edit in the browser becomes a mutation on the server.
The template modules are where the split between the old and the new shows. flow-html-components/ is the component layer for plain HTML components, and the two lit and polymer template modules are the two generations of the templating approach. The last of these is the one to read if you want to understand how the client side is actually assembled, because it is where the boundary between the JVM and the browser is drawn in code.
Where the tests live, and how a project this size checks itself
A framework with roughly thirty modules needs a test strategy that matches its size, and the directory names show a layered one.
There is flow-test-util/ and flow-test-generic/, which are shared test infrastructure, and flow-tests/ which is the main suite. Then there are the component-level suites: flow-html-components-testbench/ is a separate module for testing the HTML components, and flow-html-components/ sits next to it. The testbench naming is a Vaadin convention and refers to the browser-driven testing setup.
The split between generic and specific test modules is the sensible arrangement. A test framework that tests a data binding layer once, generically, against a matrix of cases is far cheaper than testing every component's binding behaviour separately, and the generic module is where that matrix lives.
The scripts/ directory at the root holds the build and release scripts, and the guidelines/ directory holds the design guidance, which for a component framework is as important as the code. The conventions and guidelines together are what stop a large multi-team codebase from drifting into something that only works in the module it was written in.
The whole set of these things is why a Flow upgrade is a project rather than a dependency bump. You are not just swapping a jar, you are moving between platform lines that differ in Java version, in Jakarta EE generation, in Spring Boot version, and in the component and templating stack underneath.
Maintenance, support and the practical questions before you commit
The repository is not archived, and the last push was on 2026-10-20, so the framework is actively worked on. The release list confirms the pace: 24.7.17 on 2026-10-14, 24.10.15 on 2026-10-13, and 24.4.20 on 2026-10-14. Three branches released within about a day of each other, which is the maintenance pattern you would expect for a framework that supports several version lines at once, each getting its own fixes.
That multi-line support is the key operational fact. The table marks 2.13 and 23.6 as the latest commercial releases for older runtimes, 24.4 and 24.7 as commercially supported, and 24.10 as the latest 24 minor release. If you are on 24.4, you are on a supported line and getting patches, but you are not on the newest minor.
The licence is Apache-2.0, which is the permissive one and does not oblige you to open-source an application built on it.
Two practical notes. The repository points questions to the Vaadin forum under the Flow category rather than to the issue tracker, so a usage question belongs there, and issues for Hilla are explicitly routed to a different repository, because Hilla is the separate client-side framework rather than part of Flow. And the README is a pointer document: it links to the Vaadin documentation for application development and to the contribution guide for contributors, which tells you the real content lives in those two places rather than here.
If you are evaluating Flow, read the branch table against your own runtime first. Everything else in the decision follows from whether your Java, Jakarta EE and Spring Boot versions have a line.
Editorial conclusion
Adopt Vaadin Flow if you want to build a server rendered Java web application without writing client side JavaScript, and if you are on a version line that matches your runtime, since the branch table makes the Java, Jakarta EE and Spring Boot requirements explicit per line. Do not adopt it if you need a single-page-application architecture with a JavaScript front end, because Flow's model is server driven and the project itself redirects Hilla questions to a separate repository. Before you pick a branch, read the version table and choose the line that matches your Java and Spring Boot versions, and start on a stable minor rather than on main, which the table marks as preparation work for a future release.
Frequently asked questions
What is Vaadin Flow and which part of Vaadin is it?
It is the Java framework of the Vaadin Platform, binding Vaadin web components to Java, and it is part of Vaadin 10 and later. Issues for Hilla, the separate client-side framework, are directed to the hilla repository rather than here.
Which Java and Spring Boot versions does a given Vaadin Flow branch need?
The 2.13 branch supports Java 8+ and Servlet 3, 23.6 supports Java 11+ and Servlet 3, the 24.4, 24.7 and 24.10 lines need Java 17+, Jakarta EE 10 and Spring Boot 3, and the 25.2, 25.3 and main lines need Java 21+, Jakarta EE 11 and Spring Boot 4.
Can I use Vaadin Flow independently of the Vaadin Platform version?
Not in terms of versioning. Since platform 23.0, Flow major and minor versions are aligned with platform versions, so the branch table maps each Flow branch to its matching platform release, and Flow cannot be upgraded independently of the platform.
Where should I ask questions about Vaadin Flow?
The repository directs questions to the Vaadin forum under the Flow category. For code contributions, the README points to the contribution guide in the repository first, and there is a separate code of conduct document.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/vaadin-flow)Was this useful?