Documentation versions (currently viewingVaadin 23)
New Acceleration Kits: Observability Kit, SSO Kit, and Swing Kit. Read the blog post.

Configuration Properties

Vaadin applications have configuration properties that change their behavior.

Vaadin applications have configuration properties that change their behavior. Use either system properties or servlet initialization parameters to set them.

For Spring-based applications, there are Spring-specific instructions available.

Using System Properties

When using Java’s system properties to set the Vaadin application parameters, the vaadin. prefix needs to be specified before the parameter names. The following is an example of setting a 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’s done automatically by Vaadin with default parameter values.

@WebServlet(urlPatterns = "/*", name = "myservlet", asyncSupported = true, loadOnStartup = 1,
    initParams = {
        @WebInitParam(name = "frontend.url.es6", value = ""),
        @WebInitParam(name = "frontend.url.es5", value = "") })
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 servlet parameters
If you have a system property and a servlet parameter with the same name, the system property is used.

Configuration Properties

The following list contains the properties that are defined in the com.vaadin.server.DeploymentConfiguration and com.vaadin.server.Constants classes, in alphabetical order.

Spring Boot
If you use Spring Boot, you should add the prefix vaadin. (e.g., vaadin.productionMode=true).

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


The default is true. This means that if you are using some live reload tool on the server side, the browser is refreshed automatically after the code is reloaded on the server side.


The default is false. This determines whether the VaadinSession instances of the users are serialized on server shutdown when running in development mode. When the parameter is set to false, only other HTTP session data is serialized or deserialized on development server restart. Enabling the property allows, for example, access control information to be preserved during development, so that you don’t need to log in again for each change.


The default is true in production mode. By default, in development mode all front-end resources found on the class path are included in the generated webpack bundle. When set to true, this creates an optimized bundle by including only front-end resources that are used from the application entry points. It uses bytecode scanning, which increases application start-up time.


The configuration name for the parameter that determines whether Vaadin should automatically register servlets needed for the application to work.


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


This is a location that Vaadin searches for web component files in production mode when the request comes from older browsers not supporting ES6 — the default version of the web component development language.


This is a location that Vaadin searches for web component files in production mode when the request comes from modern browsers.


Affects Flow applications only. 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 doesn’t receive a valid heartbeat from a given UI, it eventually removes that UI from the session.


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. See the Localization documentation.


Include polyfills for browsers that don’t support ES6 to their initial page. For web components to work, extra libraries (polyfills) are required to be loaded. This can be turned off if different versions or libraries should be included instead.


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 sequence by the client. This property specifies the maximum time in milliseconds that the client waits for the predecessors of a received out-of-sequence message before considering them missing. It then requests a full resynchronization of the application state from the server. The default value is 5000 ms. You may increase this if your application experiences an undue quantity of resynchronization requests. These degrade the UX due to flickering and loss of client-side-only state, such as scroll position.


This is the configuration name for the parameter that determines whether Vaadin should use bundled fragments.


This flag can be used to enable pnpm instead of npm to resolve and download front-end dependencies. By default, it’s false and npm is used. Setting it to true enables pnpm. See how to switch between npm and pnpm.


This sets the application to work in production mode. Production mode disables most of the logged information that appears on the console. It does this because logging and other debug features can have a significant impact on performance. Development-mode JavaScript functions aren’t exported. A push is given as a minified JavaScript file instead of a full size one, and static resources are cached. See Deploying to Production for more information.


Affects Flow applications only. When using the long polling transport strategy, this specifies how long it accepts responses after each network request, in milliseconds.


Affects Flow applications only. The permitted values are "disabled" or "manual". See Server Push for more information.


Affects Flow applications only. The URL to use for push requests. Some servers require a predefined URL to push. See Server Push for more information.


If this is set to true, the server includes some basic timing information in each response. This can be used for performance testing.


Returns true if the sending of URLs as GET and POST parameters in requests with content-type application/x-www-form-urlencoded is enabled.


The default is true. Returns whether sync ID checking is enabled. The sync ID is used to handle situations when the client sends a message to a connector that has been removed recently from the server.


This flag can be used to enable the server-side bootstrapping mode, which was used in Vaadin 14 and earlier versions. This option is only supported if webpack is used as the frontend build tool and not if the application uses Vite, which is the default. You can enable webpack using its associated feature flag.