Documentation versions (currently viewingVaadin 14)

You are viewing documentation for an older Vaadin version. View latest documentation

Runtime Configuration

Vaadin applications have extra parameters that may be configured to change its behavior. This section describes how to apply the properties. For Spring applications, there is Spring specific instructions available.

Using System Properties

When using Java’s system properties to set the Vaadin application parameters, the vaadin. prefix is needed to be specified before the parameter names. The following shows and example of setting the system property when executing a Maven goal from the command line:

mvn jetty:run -Dvaadin.frontend.url.es6= -Dvaadin.frontend.url.es5=

System properties can be configured for Maven plugin executions. For instance, the following example sets a Vaadin specific system property when the Jetty Maven plugin is run:


Using Servlet Initialization Parameters

Another alternative is to use servlet initialization parameters. You can use the Servlet 3.0 @WebServlet annotation, which requires you to configure your own servlet (otherwise it is done automatically by Vaadin with default parameter values):

@WebServlet(urlPatterns = "/*", name = "myservlet", asyncSupported = true, initParams = {
        @WebInitParam(name = "frontend.url.es6", value = ""),
        @WebInitParam(name = "frontend.url.es5", value = "") })
@VaadinServletConfiguration(productionMode = false)
public class MyServlet extends VaadinServlet {

Yet another approach is to use the web.xml file:

<?xml version="1.0" encoding="UTF-8"?>
  id="WebApp_ID" version="3.0"




System properties override application properties ergo if you have both properties with the same name specified, the system one will be used.

Configuration Properties

There are a number of properties that you can use to configure your Vaadin application.

This document summarizes the properties that are defined in com.vaadin.server.DeploymentConfiguration and com.vaadin.server.Constants classes.

These properties can be set from the command line as a system property, as a Servlet init parameter in the web.xml or using the @WebServlet annotation.

If you use Spring Boot then you should add the prefix vaadin., e.g. vaadin.productionMode=true.
Table 1. Vaadin properties
Property Description


Turns application to work in production mode. Production mode disables most of the logged information that appears on the console because logging and other debug features can have a significant performance impact. In addition to this, development mode JS functions are not exported, push is given as a minified JS file instead of full size and static resources are cached.


If request timing info should be made available. If true, in each response the server includes some basic timing information. This can be used for performance testing.


Cross-site request forgery protection. This protection is enabled by default, but it might need to be disabled to allow a certain type of testing. For these cases, the check can be disabled by setting the init parameter.


Vaadin UIs that are open on the client side send a regular heartbeat to the server to indicate they are still alive, even though there is no ongoing user interaction. When the server does not receive a valid heartbeat for a given UI, it will eventually remove that UI from the session. An integer value in seconds.


When it is set to true (the default is false), the session will be closed if no UI is active. Heartbeat requests are just like any other request from the servlet container’s viewpoint. This means that as long as there is an open UI, the session never expires even though there is no user interaction. You can control this behavior by setting an init parameter named closeIdleSessions to true.


The permitted values are "disabled" or "manual". Please consult Server Push Configuration documentation.


It is the url to use for push requests. Some servers require a predefined URL to push. Please consult Server Push Configuration documentation.


Returns whether sync id checking is enabled. The sync id is used to gracefully handle situations when the client sends a message to a connector that has recently been removed on the server. By default, it is true.


Returns whether the sending of URL’s as GET and POST parameters in requests with content-type <code>application/x-www-form-urlencoded</code>is enabled or not.


When using the long polling transport strategy, it specifies how long it accepts responses after each network request. Number of milliseconds.


In certain cases, such as when the server sends adjacent XmlHttpRequest responses and push messages over a low bandwidth connection, messages may be received out of order by the client. This property specifies the maximum time (in milliseconds) that the client will then wait for the predecessors of a received out-order message, before considering them missing and requesting a full resynchronization of the application state from the server. The default value is 5000 ms. You may increase this if your application exhibits an undue amount of resynchronization requests (as these degrade the UX due to flickering and loss of client-side-only state such as scroll position).


Include polyfills for browsers that do not support ES6 to their initial page. In order for web components to work, extra libraries (polyfills) are required to be loaded, can be turned off if different versions or libraries should be included instead.


A location Flow searches web components' files in production mode when the request is coming from older browsers, not supporting es6, default web components' development language version.


A location Flow searches web components' files in production mode for requests from modern browsers.


Configuration name for the parameter that determines if Flow should use webJars or not. If set to true, webjars would be ignored during request resolving, allowing Flow to use an external source of web components' files.


Configuration name for the parameter that determines if Flow should use bundled fragments or not.


I18N provider property. To use localization and translation strings the application only needs to implement I18NProvider and define the fully qualified class name in the property i18n.provider. Please consult I18N localization documentation.


Configuration name for the parameter that determines if Flow should automatically register servlets needed for the application to work.


When set to true, enables Vaadin 13 compatibility mode (Vaadin uses Bower and Webjars to handle frontend resources instead of npm and webpack). The purpose of this mode is to ease migration and it will no longer be supported in Vaadin 15. See Compatibility mode in Vaadin 14 Migration Guide for more information.


By default, in development mode all frontend resources found on the class path are included in the generated Webpack bundle. When set to true, creates an optimized bundle by including only frontend resources that are used from the application entry points (this is the default in production mode). Uses bytecode scanning which increases application startup time.


This is by default set to true, which means that if you are using some live reload tool on the server side the browser will be refreshed automatically once code is reloaded on the server side. See Live Reload.


This flag can be used to enable pnpm instead of npm for resolving and downloading frontend dependencies. By default it is false and npm is used, but setting it to true enables pnpm. More information in the switch between pnpm and npm documentation.

When set to true, the exact npm package versions defined in the package lock file is installed during the build. In practice, npm ci is run instead of npm install, or if you use pnpm, the install command runs with --frozen-lockfile parameter. Defaults to false.