Documentation versions (currently viewingVaadin 24)

Configuration Properties

Setting configuration properties to change the application behavior.

You can change the behavior of Vaadin applications by setting the configuration properties. You can set them either through the system properties, or the servlet initialization parameters. See the full list of properties for details.

See also the Spring-specific instructions for Spring-based applications.

Using System Properties

When using Java system properties to set Vaadin application parameters, the vaadin. prefix must be specified before each parameter name. The following example shows how to set the pnpm.enable system property when executing a Maven goal from the command-line:

mvn jetty:run -Dvaadin.pnpm.enable=true

You can configure system properties for Maven plugin executions. For instance, the following sets a Vaadin-specific system property when running the Jetty Maven plugin:


Servlet Initialization Parameters

Another option for setting configuration properties is to use servlet initialization parameters. Use the Servlet 3.0 @WebServlet annotation. This requires you to configure your servlet, unless you want Vaadin Flow to do it, using default parameter values.

@WebServlet(urlPatterns = "/*", name = "myservlet", asyncSupported = true, loadOnStartup = 1,
    initParams = { @WebInitParam(name = "pnpm.enable", value = "true") })
public class MyServlet extends VaadinServlet {

Yet another approach is to use the web.xml file. Below is an example of one:

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



System Properties Override Servlet Parameters
When a system property and a servlet parameter have the same name, the system property is used and the servlet parameter is ignored.

Configuration Properties

The following table contains the properties that are defined in the com.vaadin.server.DeploymentConfiguration and com.vaadin.flow.server.Constants classes. They’re listed in alphabetical order. If you use Spring Boot, you should add the vaadin. prefix to them (e.g., change brotli to vaadin.brotli).

Property Name Default Value Description



Determines whether pre-compressed Brotli files should be used if accepted by the browser. Brotli files are created during a production build. The property is used only in production mode. Set to false if you want to serve uncompressed static resources.



Closes the Vaadin session if no UI is active. A UI is considered active if it’s open on the client-side and has any activity — besides heartbeat requests. By default, heartbeat requests keep the Vaadin session open even when there is no user interaction. Set to true to close idle sessions. See heartbeatInterval below.



Defines the hosts allowed to access Vaadin development tools. A comma-separated list of allowed hosts should be provided as the value. The ? and * wildcards can be used (e.g., 192.168.1.*,172.17.?.*). Loopback addresses are always allowed, regardless of the value set here.



Enables live reload. When using a server-side live reload tool, the browser is refreshed after code is rebuilt on the server. Set to false to disable automatic reloading of the browser. This applies only to development mode.



Optimizes frontend resource bundles. All frontend resources in the classpath are included by default in the generated bundle in development mode. When set to true, the frontend build creates an optimized bundle by including only frontend resources that are used from the application entry points. It uses bytecode scanning, which increases application start-up time. Set to false to skip the optimization in production mode.



Enables session serialization. When session serialization is enabled, UI instances and registered StreamResource instances are serialized or deserialized when restarting the development server. When set to true, for example, access control information can be preserved during development so that you don’t need to log in for each change. This applies only to development mode.



Enables the Component Locator tracker utility. Set to false to disable. With it disabled, the Component Locator tool cannot identify any components. This applies only to development mode.



Enables Vaadin to collect usage statistics that can guide further development. Statistics are collected based on features that are used in the application. No data is collected in production mode. Some usage statistics are collected through the web browser. See the client-side collector repository for instructions on how to opt out. This applies only to development mode.



Disables automatic servlet registration that’s required by Vaadin applications. You must register Vaadin servlets if set to true.



Disables cross-site request forgery protection. The protection is enabled by default. You should keep it enabled — except for certain types of testing.



Enables the client-side bootstrap page to include the initial JSON data fragment.



If {@code true}, navigation error views implementing HasErrorParameter can be rendered for exceptions during RPC request handling.



Enables development using the frontend development server instead of an application bundle. This applies only to development mode.


300 seconds (i.e., 5 minutes)

Sets the heartbeat interval time. UIs that are open on the client-side send a regular heartbeat to the server indicating that they’re still active even without ongoing user interaction. When the server doesn’t receive a valid heartbeat from a given UI within a certain amount of time, it removes that UI from the session. The interval value is expressed in seconds. See also closeIdleSessions.



Sets the fully-qualified name for the internationalization provider class. To translate strings for localization, the application should implement the I18NProvider interface and define the class name in the i18n.provider property. See the Localization documentation for details.


5000 ms (i.e., 5 seconds)

Sets the maximum time in milliseconds that the client waits for predecessors of an out-of-sequence message, before considering them missing and requesting a full state resynchronization from the server. For example, when a server sends adjacent XmlHttpRequest responses and pushes messages over a low-bandwidth connection, the client may receive the messages out of sequence. Increase this value if your application experiences excessive resynchronization requests. However, be aware that it degrades the UX with flickering and loss of client-side-only states, such as scroll position.



Enables pnpm, instead of npm, to resolve and download frontend dependencies. It’s set by default to false since npm is used typically. Set it to true to enable pnpm. See Switching Between npm, pnpm and bun for more information.



Enables bun, instead of npm, to resolve and download frontend dependencies. It’s set by default to false since npm is used typically. Set it to true to enable bun. See Switching Between npm, pnpm and bun for more information.



Sets the application to work in production mode. This disables most of the logged information to improve performance — information that appears on the server and browser console. Development mode JavaScript functions aren’t exported. Any push is given as a minified JavaScript file instead of a full-size one, and any static resources are cached. See the Deploying to Production for more information. Set to true when building applications for public deployment.


-1 (i.e., no timeout)

Sets the timeout in milliseconds for network requests when using long polling transport. If you have long polling enabled with a proxy that has a timeout, set pushLongPollingSuspendTimeout to less time than the proxy timeout for clients to reconnect.



Enables server push. The permitted values are disabled, manual, and automatic. See Server Push for more information.



Specifies the servlet mapping used for bidirectional (i.e., "push") client-server communication. Some Java application servers require special context. For example, you can specify websockets with this.



Whether to use React Router, add React core dependencies, React integration helpers and Vaadin’s provided React components (@vaadin/react-components). Fallbacks to vaadin-router, excludes all React dependencies and adds Lit dependencies, if set to false.


true for development mode; false for production mode

Includes basic timing information in responses that can be used for performance testing.



Enables synchronized ID checking. The synchronized ID is used to handle situations in which the client sends a message to a connector that has been removed from the server. It’s set to true, by default. You should only disable it if your application doesn’t need to stay synchronized, and suffers from a bad network connection.


300 seconds (i.e., 5 minutes)

Sets the number of seconds that a Vaadin Flow application embedded as a Web Component waits for a reconnect before removing the server-side component from memory.



When production mode is enabled, the Vaadin session lock check is done according to this setting. By default, the check is done only if assertions are also enabled: this is to avoid the small performance impact of continuously checking the lock status. Alternative values are 'log' to log a warning, or 'throw' to fail with an IllegalStateException. The 'log' option also logs a full stack trace, enabling you to determine any problematic calls to Vaadin UI components from background threads. This is since Vaadin Flow version 24.4.

Vaadin Plugin Properties

The following table contains the properties that are used only by the Vaadin Maven and Gradle Plugin, and are not applicable for deployment configuration:

System Property

Plugin Configuration


Default Value


Determines whether npm ci is run, instead of npm i, for production frontend builds. If you use pnpm or bun, the install command runs with the --frozen-lockfile parameter. The build fails if the package.json and the lockfile have mismatching versions.



Forces Vaadin Flow to create a new production bundle, even if there is already a usable pre-compiled bundle. This is required usually when creating an optimized production bundle, and to load component sources to the browser on demand — such as when opening a route where these components are used.



Prevents a frontend development bundle from being re-built, even if Vaadin Flow decides to use an existing compiled development bundle. This is mainly needed when re-bundling checker in Vaadin Flow has problems leading to false re-bundling, and one needs a workaround while it’s being resolved.