Server Settings


The Servoy Settings section shows all the editable Servoy Settings, grouped per area. Each setting has an info button that can be clicked for info about the setting.

Restart required after editing settings After editing one of more settings, the changes need to be explicitly saved using the Save button at the bottom of the page. In order for the changes to take effect, a restart of the Servoy Application Server is required.


Security setting:


default: false It can be acceseed on the Security settings section of the admin page. This is a global setting for the Servoy Application Server to enable or disable sanitizing of data from a dataProvider when shown in elements.

When set to false (default) Servoy will protect against XSS attacks by sanitizing data before shown. When set to true, sanitizing of data displayed in elements will be disabled for this application server (makes vulnerable to XSS attacks). Setting this to true is highly discouraged, your system may be vulnerable to XSS attacks. Sanitizing of data can be turned off and on at solution or element level as well, see Security: Cross-site Scripting (XSS).


The Locale Settings are the default values for each started Servoy Client.

If specified on the Admin Page, they override the Locale Settings of the user environment. Within a Solution the developer can choose to override Locale settings programmatically.

Locale settings:


The default locale It should be a language code and a country code separated by a comma. Example: en,US


The default number format. This format will be applied to all number fields, that do not have the format set at the field or table level. Example: #.## Legend: # will be any valid number: 0-9 . is the decimal separator , is the grouping separator


The default integer format. This format will be applied to all integer fields, that do not have the format set at the field or table level. Example: #,###.00 Legend: # will be any valid number: 0-9 . is the decimal separator , is the grouping separator


The default date format. This format will be applied to all date fields, that do not have the format set at the field or table level. Example: dd-MM-yyyy


This property is ignored for NGClient solutions, use the format property (Use local time) per field to dictated if the timezone should be used in client or not. When true the clients timezone will be used to convert to the server/database timezone, it is recommended to use true as default to always see the correct/same dates/times in all clients (regardless of their timezone), but this means that dates are then not converted to the different timezones of clients (10:00 is always 10:00).

Internationalization (i18n)

The Internationalization Settings provide the option to set a default Server and Table where i18n keys are stored. These default settings can be overwritten per solution. For more information on Internationalization, see Internationalization - I18N.

Locale settings:


The server which contains i18n messages


The table which contains i18n messages

NG Client

The following settings are applicable to NG Client:


Testing support property for generating the data-svy-name attribute on forms and form elements. default: false


Enable grouping of resource files, like js and css, to reduce the number of page requests. default: true


Comma separated list of allowed origins for websocket requests, <Host> for checking against host header (default) or <None> disabling the check.


The number of seconds after which a disconnected client will be cleaned up. Within this time a client can be reconnected. Default 60.


Context path of your NGClient url. Default will be request.getContextPath(). If using a proxy you may need to configure this. For example if you map through reverse proxy on root a WAR that is deployed on tomcat on a context. Then the context path should be overwritten with / (the root). Better is to also deploy it on tomcat as the ROOT.WAR

Filename of an html template (no <html> and <body> tags) which will be shown when an error occurs. It resides in ROOT (application_server/server/webapps) for the NG Client.

NG Client error page example:

<div style='padding:40px;' ng-controller="InternalServerErrorController">
    <div class="bs-callout bs-callout-danger" >
    <h1>Internal Server error </h1>
    <p>There was an error at the server side</p>
    <pre ng-if='error.stack' ng-bind='error.stack'></pre>

Filename of an html template (no <html> and <body> tags) which will be shown when the session times out. It resides in ROOT (application_server/server/webapps) for the NG Client.

NG Client page expired example:

<div style='padding:40px;' ng-controller="SessionExpiredController">
    <div class="bs-callout bs-callout-danger" >
    <h1>Page Expired</h1>
    <p>The page you requested has expired.</p>
    <p><a ng-href="{{redirectUrl}}">Return to home page</a></p>


The URL which should be used or redirected to when the session expires.


The number of seconds a redirect should happen, -1 or null means no redirect, 0 immediate redirect, >0 x seconds wait before auto redirect.


Sets the maximum upload size, in kilobytes, that a user can do through the upload/media field. 0 or not set is no maximum, used be NG, Web and RestWS uploads.


Sets the threshold in kilobytes, when a temp file on disk should be made when a file is being uploaded for NG Client or RestWS plugin(default is 50K).


Sets the upload dir that the file upload will use to store temp files when the upload size threshold is reached. It is recommended to set this to a file system where you also want to store the actual uploaded file, so that you can use JSFile.renameTo(). Rename only works within the same file system (so in windows C: to C: not C: to D:), the default value is the '' system property.

Content Security Policy (CSP)

For the NGClient we have on the admin page a number of properties that configures the CSP headers we set when a NGClient is launched.

For more information on CSP visit: Content Security Policy (CSP) - HTTP | MDN (

You can disable it fully with the boolean property, but this should be avoided:


Set the Content-Security-Policy header to mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. default: true

The other properties:


frame-src Content-Security-Policy directive, default: * data:


frame-ancestors Content-Security-Policy directive, default: 'self'


font-src Content-Security-Policy directive, default: * data:


img-src Content-Security-Policy directive, default: * data: blob:

style-src Content-Security-Policy directive, default: * 'unsafe-inline'


form-action Content-Security-Policy directive, default: 'self'

Are there if you want to run the ngclient withing an iframe (frame-src, frame-ancestors) or want to relax certain behaviors even more for loading if styles/fonts/images.

Servoy has defaults (see the info buttons on the admin page) so that the basic NGClient deployment works where most of the stuff are all coming from the same host "self".

Servoy only enables this for when we detect a browser that can handle CSP level 3, because we need for scripts/css the "strict-dynamic" property: strict-dynamic Explained (

All scripts/links have a nonce which is also specified in the CSP header to allow all the scripts that Servoy generates from the web packages in the index.html (main solution index).

In NGClient1 we still allowed "eval" to happen, this is not allowed anymore for NGClient2, because of this you can't push functions as string to the client and eval it to get a function, if a component needs a property like that the property type needs to be "clientfunction" instead of "string" or "tagstring".

This way NGClient2 will generate a script from that on the server and that will be loaded as a normal js file.


The Performance Settings provides options to specify memory settings for Servoy Clients.

Performance settings:


Greater than 0 will enable object pooling on server for non mutable objects. default: 50000


Disables all client data notifications (inserts, updates, deletes). Should be used for performance testing only! default: false


When locks are acquired within a database transaction, also try to get an update lock for the records in the database. default: false


The Servoy Admin page exposes several Branding settings on it's main page. By enabling Branding support by setting the servoy.branding setting to true and providing custom values for the other properties, the first part of the user experience can be customized.

Branding settings:


Enable branding support default: false


Application title shown in NG client


The Admin Settings offer options to set several groups of properties, as well as the email address of the Servoy Application Server administrator.

Admin settings:


Allow solution code to access the repository server. When turned off, soloutions using tables in the repository_server may receive error: You do not have access to view this data. default: false


Allow logging of client connection/disconnection statistics. The client stats table is situated in log server (so log server should be defined if this option is enabled). default: true


The email address to use for notifies about license usage, make sure the mail (server plugin) properties are set as well to enable mail to be sent.


This setting controls the maximum number of clients per solution displayed initially on the clients page. If not set or <0, it displays all clients.


With this setting you can enlarge the maximum allowed length of the database sequence text value to a max of 200, instead of the default 50, the repository has to be created with a Servoy 8.2 install to support this. Check your database what max text length it does support for the sequences!

System properties for the application server (these will also be passed to the clients as properties). Example: For more info please refer to the Apache Tomcat Documentation

User properties to be passed to the clients. Example: user.UserProp=userPropValue


Log settings:

Do not report cases when not all records are loaded into the valuelist, i.e. when there are more than 500 records. default: true


Print javascript stacktrace in Servoy log. default: true

Solution Settings

The Solution Settings are global settings that affect all solutions hosted on the Servoy Application Server.


Enable/Disable solution browsing; if disabled (false), it's only possible to open solution by deep-linking URLs. default: enabled (true)

Foundset loading and saving tuning

Servoy loads a foundset by first retrieving the PKs from the database. This retrieval is done in chunks: when the foundset is initialized, the first chunk is retrieved, consecutive chunks are retrieved when needed.

The actual record data is also retrieved from the database in chunks.

The size of the different chunks are controlled by 3 properties that can be set in the


Chunk size for foundset PK retrieval default: 200


Chunk size for record data retrieval default: 30


Chunk size for related record retrieval For the initial load of related records both the PK's and data are retrieved in one query default: 2 *servoy.foundset.chunkSize


(since 2020.12) This only works for inserts of records that are after each other (without another record from another datasource in between). It does now have side effects:

  • In statementBatching if you insert 10 records of the same datasource, that is now always then also in a transaction (not depending if you started a transaction) because it goes into the same (single) batch statement.

  • Because its now a transaction and a single statement to the db server, no matter if you are your self already in a transaction or we do it automatically now, if something goes wrong in 1 of the records, all records are failed, because databases don't tell us which one really failed, we would know this previously, and nothing is inserted

  • That nothing inserted was already the case in transaction mode, but this is with this property to true different in none transaction mode, which did do the inserts until the failure and now it fails the same as in transaction mode. default: false


(since 2020.12) By default Servoy will not query for related records if the relation is a pk → fk relation. So if the relation has on the primary side at least all the primary keys specified. Because this scenario should already not be possible in a good designed database (if there is a fk→pk constraint specified on the child table). Child records should not already exist if there is no Parent record already. So Servoy does not ask the database for data in this scenario. Related lookups on not yet saved Parent records should only be used to make related records, not to expect to get data. By setting this property to "true" you can force Servoy to query for data even for such scenario's default: false

The values can be modified in an attempt to increase performance. The optimal values differ per application, thus no guidelines are available for alternative values. Tuning needs to be done by altering the values and monitoring the performance afterwards. The defaults are set based on averages.

Last updated