vaadin/platform is the aggregate build, and its version table is the real documentation

An aggregate of parts, and a routing note for bug reports

The repository description says two things that set expectations. Vaadin platform 10 and later is a Java web development platform based on Vaadin web components, and if you do not know which repository your bug report should be filed in, use this one and the maintainers will move it to the right one. The second sentence is the more revealing, because it tells you this repository is not where the work happens. The About section repeats it: this repository gathers all parts of the Vaadin platform into a single package, ensuring all the parts work together. So the aggregation is the product. The parts, the web components, the build tooling, the development server pieces, the plugins, the starters, all of them are separate concerns that have to agree on versions, and this is the place where that agreement is expressed and built. The README also points readers who want an overview of Vaadin to a different repository, and to a release model page, and to a build guide in BUILD.md for producing the platform artifacts locally. The audience for this repository is therefore two groups. The first is a developer who has to build, extend or integrate the platform, and who needs the whole set of parts at compatible versions. The second is an architect deciding which release line to standardise on, and the version table in the README is the single most useful page for that decision.

The version table maps each line to a Java and Jakarta generation

The supported versions table is the core content of the README, and it is more informative than it first looks because each row names a baseline. Branch 14.14 is the latest commercial release with Java 8 and Servlet 3 support, and 23.6 is the same idea for Java 11 and Servlet 3. The 24.x lines move to the modern stack: 24.4, 24.7, 24.9 and 24.10 are all commercially supported and all require Java 17, Jakarta EE 10 and Spring Boot 3, with 24.10 marked as the latest commercial release in that group. The 25.x lines go one step further: 25.1 is a maintenance release on Java 21, Jakarta EE 11 and Spring Boot 4, 25.2 is the latest release on the same baseline, 25.3 is a pre-release on that baseline, and main is where 25.4 preparations happen. Read as a whole, the table is a compatibility map with three distinct eras. The pre-Jakarta era, Servlet 3 and Java 8 or 11, is still supported commercially. The Jakarta EE 10 era on Java 17 is the mature, commercially supported line with several patch versions listed. The Jakarta EE 11 era on Java 21 and Spring Boot 4 is where new work is going, and it is still pre-release in part. For an organisation with an existing Java 8 or Servlet 3 estate, the fact that 14.14 is still the latest in its row is a real answer about how long the old baseline will be maintained.

The repository listing reads like a map of the platform

The top level directory listing is long, and it is a good diagram of what the platform consists of. The vaadin/ directory holds the main artifact, and alongside it sit vaadin-core/, vaadin-core-components/, vaadin-core-internal/, vaadin-core-jandex/ and vaadin-core-sbom/, which suggests a core split into the public artifact, the component layer, an internal layer, and two build-time concerns around indexing and SBOM generation. The dev side is vaadin-dev/, vaadin-dev-bundle/ and vaadin-hybrid-dev-bundle/, with vaadin-prod-bundle/ on the production side, so there is a clear separation between what runs while you develop and what ships. The enterprise edition lives in vaadin-ee/. Then there is the tooling for consuming the platform: vaadin-maven-plugin/, vaadin-gradle-plugin/, vaadin-core-sbom/, vaadin-platform-sbom/ and vaadin-core-jandex/, plus the integration surfaces in vaadin-spring-boot-starter/, hilla-spring-boot-starter/ and vaadin-quarkus/. The test modules are informative as well, with vaadin-testbench/, vaadin-testbench-junit5/ and vaadin-testbench-junit6/, dedicated servlet container tests, a platform test module, several hybrid test modules, a reload benchmark, and a platform gradle test. The presence of a jandex directory and an sbom directory next to the core tells you the platform is packaged with index metadata and an SBOM in mind, and the SBOM badge in the README header links to a workflow that produces one for each push.

Building it locally is a documented, separate step

The README does not describe a build command inline, and the reason is a single sentence: to build the Vaadin platform artifacts locally, see Building the Vaadin platform in BUILD.md. The repository contains that file, and the build system underneath is Maven, since the root carries a pom.xml alongside a scripts/ directory, a .github/ directory for the workflows, and a versions.json file that most plausibly records the version alignment across the modules. The build also has a Maven Central badge pointing at the com.vaadin vaadin-bom metadata, which tells you the published artifact of interest to consumers is a BOM, the standard way to pin a set of versions across a platform of many modules. The SBOM workflow badge and the sbom modules point in the same direction, and if your organisation has supply chain requirements, the fact that the platform ships SBOM generation and Jandex indexing as first class parts of the build is a genuine consideration in favour. The other side of the same picture is that the dev bundle and prod bundle split means the artifact you deploy is not the artifact you develop against, and the dev server pieces are present in the repository but not in the production bundle. That distinction is the sort of thing that only becomes visible when you read the module list rather than the marketing page.

Where the documentation and the release feed disagree

Two inconsistencies in the README are worth flagging, because a reader making a version decision will notice them. The first is between the supported versions table and the release list. The table marks 25.2 as the latest release and 25.3 as a Vaadin 25.3 pre-release on the main branch line of development, yet the recent releases list shows 25.3.3 published on 2026-10-20, 24.10.12 published on 2026-10-19 and 24.9.24 published on 2026-10-19. A patch release numbered three is a released version, so the table's description of 25.3 as a pre-release and of 25.2 as the latest release no longer matches what is being published. The second is quieter and matters more operationally. The 24.9 and 24.10 lines are still receiving patch releases on the same day as the 25.3 line, which is the platform's support model at work, and the table still lists 14.14 and 23.6 as the latest in their rows. So the practical reading is that several lines are alive at once, and the table, which is a manual summary, lags the release feed. The README does offer a link to the release model page and a release list for the platform, and for a decision about which line to adopt, the release feed is the more current source. There is also no licence information to go on. The licence field for this repository is recorded as unknown, and the README does not state terms, so anyone redistributing or embedding the platform artifacts needs to look at the licence inside the artifacts rather than at the repository page.

Editorial conclusion

vaadin/platform is worth reading before you pick a Vaadin line, because the version table is the clearest statement of what each release requires and how long it will be maintained, and it is the one place that shows all the supported lines side by side rather than a single current number. It is not the repository to depend on directly, since it exists to aggregate the modules, and the README says bug reports should go to the repository that owns the part. It is also the wrong place to look for the licence, because the licence field for this repository is recorded as unknown. Before you upgrade, read the supported versions table against the Java and Jakarta versions your deployment actually runs, and check BUILD.md for how to build the artifacts yourself.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. vaadin/platform on GitHub