One of the biggest changes existing Vaadin users will notice in version 25 is how much simpler the build setup has become.
In Maven-based projects especially, build files now contain far fewer Vaadin-specific configurations. They’re cleaner, easier to read, and less intimidating for newcomers. At the same time, Vaadin 25 improves compatibility with various cloud deployment environments — no more special tricks required.
Production-Ready by Default – Buildpack Compatible
One of Vaadin’s long-standing goals has been to shield Java developers from front-end development complexity, builds included. The front-end build is still there, of course, but Vaadin tooling takes care of it both in development mode and during production builds.
Previously, the production build had to be manually activated using the production profile in pom.xml. This very Vaadin-specific quirk often confuses even experienced Java developers when starting with Vaadin development.
In Vaadin 25, there’s no longer a separate production profile in pom.xml. The build — e.g. invoked with mvn package — now creates production-ready artifacts. The Vaadin build plugin automatically generates the optimized front-end bundle for deployment and development mode tooling is excluded by default (previously excluded using the production profile)
This change not only improves the deployment experience but also makes Vaadin projects instantly compatible with modern deployment pipelines, including Buildpacks used by many PaaS services. If you have an in-house CI/CD setup, you’ll likely find that Java defaults just work with your next Vaadin project.
Still “DX First”
Developer experience remains our primary goal. The new build setup is just as smooth to work with as before — and in many cases, even more seamless.
Recent Spring Boot updates have improved how optional dependencies are handled in Maven projects. This enhancement now benefits Vaadin as well: Vaadin’s development mode can be included as an optional dependency, without interfering with the production builds.
In practice, this means:
- When you start your app from your IDE (via the
mainmethod) or runmvn spring-boot:run, development mode is activated. - When you build your app (e.g., with
mvn package), Vaadin’s development-time tooling is excluded and the front-end bundle is optimized for production.
When developing classic WAR-packaged projects (JakartaEE/CDI or plain servlet), developers should now activate the development profile in their IDE (or have their own in settings.xml), to make Vaadin Copilot and other development time tooling work like before. When deploying your project, this production-first approach makes deployment as simple as with Spring Boot projects.
Even Better on Quarkus
Similar improvements have landed for Quarkus projects — and we’ve gone even further there, thanks to Quarkus’s flexible extension model.
With Vaadin 25, you no longer need the vaadin-maven-plugin or Gradle plugin for Quarkus projects. Just adding the Vaadin extension (a single dependency!) and you’re ready to go:
quarkus dev(or the corresponding Maven goal) starts your Vaadin app in development modemvn packagebuilds a production-ready package
Behind the scenes, Quarkus tooling uses the exact same logic as the Maven and Gradle plugins - just a bit more seamlessly.
Try now with the updated starter
Vaadin 25 is already well into its beta phase. We’re still polishing a few things, but we’d love to get your early feedback — especially on these build improvements and many other new features.
Testing with a fresh Vaadin 25 project is easy — use your IDE’s Vaadin project wizard (and choose pre-release version) or check out these updated starter projects:
If you want to try Vaadin 25 in an existing project, check the upgrade guide in the V25 branch of the Vaadin Documentation.