Version History

Applies to VirtServer 3.21.0, last modified on June 11, 2024
Important Notice for VirtServer Customers:

ReadyAPI has fully transitioned to the ID-based SmartBear License Management (SLM) system. We strongly encourage users still utilizing file-based licensing, including key-based and ProtectionLS floating licenses, to migrate before the September 1, 2024 deadline to avoid commercial impact. Please be aware that support for file-based licensing has ended and technical support is no longer available, which may lead to unresolved technical issues.

If you cannot migrate from file-based licensing before September 1, 2024, it is crucial to contact your SmartBear representative immediately to align with our deprecation plans and avoid disruptions. Additionally, retaining file-based licenses for any solution expansions or renewals after this date will result in a service charge of up to 30% of the renewal or expansion invoice value to cover the extension costs. To avoid these charges, please initiate your migration now.

If you are still in the process of migrating or have yet to start, contact your Account Manager or SmartBear representative today. Our teams are ready to assist with smooth transition strategies. For additional support, please log a request with our Customer Care Team, who are standing by to help.

3.21.0 (June 11, 2024)

  • When the CLI detects that the connecting VirtServer is OIDC enabled, it will make a Client Credentials request to the OIDC provider URL. Using the provided client credentials, it allows a machine to access VirtServer with either admin- or regular user-level privileges to perform tasks.

  • The VirtServer CLI can now function through a proxy for logging in, installing licenses, and managing virtual servers.

    At the application level, VirtServer can utilize ReadyAPI's proxy configuration, provided ReadyAPI is installed and configured on the same machine as VirtServer.

  • We now offer settings configurations through arguments or parameters that allow customers to add their own Okta user groups for Admins and Users.

  • Fixed a bug that allowed users to log out of their Okta session if they tried to log in as an Okta user without any group. The message "Error. VirtServer requires users to be part of application-specific groups. Please contact your OIDC Administrator for support." is shown, and the user can log out of their existing Okta session to log in again and be authenticated anew.

  • We added support so that Okta tokens can be automatically refreshed before expiration ensuring uninterrupted access to the application. This is based on the token expiry settings in Okta.

  • We have improved the error messages.

Jenkins Plugin 1.19.0 (May 28, 2024)

  • We released Jenkins Plugin 1.19.0 which requires Jenkins 2.440.3 or later. This is part of the ongoing maintenance to update existing libraries and plugins to the latest versions of the product.

3.20.0 (May 02, 2024)

  • VirtServer now supports customers using OIDC for user authentication and authorization in version 3.20.0 with the following additions:

    • User authentication for VirtServer Web UI and CLI, as well as the ReadyAPI VirtServer panel. When VirtServer is configured in a customer's Okta environment, you can log in using PKCE flow to VirtServer Web UI or Device Login for CLI.

    • OIDC support for user management for the Jenkins + Maven plugin will be included in future releases.

    • License installation for SLM on-premise 2.1.1 (where OIDC is configured for SLM on-prem license server) is also part of this release for Windows, Linux, Platform Independent, and Docker.

  • We've updated DropWizard in VirtServer to version 4.x. Jetty 10.0.x has introduced stricter SNI host checking, which may cause issues when making requests over HTTPS. You can read more about here. Visit the VirtServer Settings page for documentation on configuring this setting.

  • We resolved a bug where the grace period wasn't functioning as expected, allowing Virtual Services to be started during the grace period when only virtual services that are already running should be operational during this time.

  • Licenses are now installed in the $HOME/.readyapi directory instead of $HOME to prevent license activation issues some users faced after the latest ReadyAPI update.

  • We fixed an issue causing VirtServer to lose its license after stopping VirtServer as a service and starting it as an application.

  • We addressed an issue causing the request body in the Transaction log in ReadyAPI - Virtserver panel to be empty when an incoming request to a virtual service in VirtServer had Content-Type: application/x-www-form-urlencoded.

  • We fixed an issue causing problems when changing the response delay value, where sometimes the value wouldn’t update.

  • We’ve updated a few third-party libraries to make the product even more reliable and secure. Please see here for the full list.

3.19.0 (January 24, 2024)


In VirtServer 3.19, we've made some updates to handling the SLM license. Before upgrading, uninstall your SLM license using the Web UI or CLI. After the upgrade, reinstall the license.

the license token file is now stored in the .virtserver folder instead of .readyAPI.

  • We enhanced security by migrating SLM authentication to use Auth0.

  • We improved the Docker container shutdown behavior, sending a call to the unlock endpoint of the SLM server for correct license unlocking during product shutdown. License is made available immediately for next user.

  • We made changes to license installation when ReadyAPI and VirtServer licenses are available in the same SLM server.

  • We fixed an issue with SLM, ensuring the license reinstalls correctly upon product restart.

  • If an error occurred while entering a new user, the 'Add User' button would remain disabled even after it was rectified. This issue is resolved.

  • We added audit log detail displaying the last ping during the grace period. It will help to investigate issues with the SLM server.

  • We resolved a problem where setting response delay from the Behavior tab did not update correctly.

  • We’ve updated a few third-party libraries to make the product even more reliable and secure. Please see here for the full list.

  • ReadyAPI is now updated to support VirtServer CLI 1.18, incorporating its latest capabilities.

  • Added a new CLI command Virts -stopall, which can be selected to stop a working virtual service.


We've identified a recurring SLM licensing issue where VirtServer when started as an application or run as an operating system service, restarts in the opposite state after system updates. The impacted scenarios include:

  • Started as an application and restarted as-a-service after updates.

  • Started as-a-service and restarted as an application after updates.

  • While this primarily impacts Windows users, there have been reported cases on Linux as well.

In these scenarios, the license tokens are handled differently in the registry during restart, leading to inconsistent results during reinstallation. We advise users to restart VirtServer in the same mode as the original install (either as an application or a service) until further notice. Our team is actively working on resolving this issue, and a fix will be released soon.

3.18.0 (October 26, 2023)

  • We added a new feature to view and download the Virtual Service Transaction Log through the Web UI. This feature covers SOAP and REST services, with support for other protocols planned in future releases. Read more about transaction log.

  • We added a diagnostic probe which adds the network probe responses when creating a diagnostics report. This helps to verify VirtServer is able to see network endpoints such as SLM License servers.

  • We updated support for matching TCP requests using Groovy scripts at service level, a feature introduced in ReadyAPI 3.47. Learn more about matching TCP requests.

  • Fixed a bug introduced in VirtServer 3.17, which affected the behavior of dispatch parameters.

  • VirtServer is updated to align with ReadyAPI 3.49 and the latest version of Microsoft Excel in data-driven testing (suporting .xlsx).

  • Updated some libraries as part of ongoing maintenance work.

3.17.0 (June 14, 2023)

  • From October 2023, we won't provide file-based licensing. Instead, we will replace it with SmartBear ID-based licensing - With VirtServer 3.17.0, we extend support for SmartBear ID-based licenses hosted on SmartBear licensing servers. You can now specify your access Key in the license installation process and request a license, once is it made available and assigned on As we approach the October milestone, we're actively encouraging customers to transition over. Now is the time to start planning that transition. You should immediately engage with your SmartBear Account Manager to understand the steps involved in transitioning and getting started. Please read here to learn more.

  • As part of our product maintenance progam, we are also upgrading the underlying H2 database to the latest version V2.1. The upgrade will happen as part of your next installation or upgrade and will migrate your data and users without you needing to do anything. However, we understand that you may have questions or in the event of the upgrade experiencing issues, please contact support if you need help before of during the upgrade process. You can also request a technical session with our Solution Engineering team if you would like some help. Please contact your SmartBear Account Manager to arrange.

3.16.0 (March 2, 2023)

  • From October 2023, we won't provide file-based licensing. Instead, we will replace it with SmartBear ID-based licensing - SmartBear ID-based licensing (also known as SmartBear License Management or SLM), is a new license management option that we started using in ReadyAPI 3.8.1. Support for SmartBear ID-based licenses is now being added to VirtServer 3.16. It is more reliable and convenient than the license type used in the previous product versions. As we approach the October milestone, we're actively encouraging customers to transition over. Now is the time to start planning that transition. You should immediately engage with your SmartBear Account Manager to understand the steps involved in transitioning and getting started. Please read here to learn more.

    • Support for SmartBear ID-based licenses is starting with offline (Customer on-premise) deployment in Q1 2023 (where the customer hosts the license server on-premise). We will add support for online (SmartBear hosts the license servers) later in 2023.

  • As part of our product maintenance program, we updated the following:

    • JRE to jdk-17.0.6.

    • We’ve updated a few third-party libraries to make the product even more reliable and secure. Please see here for the full list.

  • We fixed a bug where the transaction log was not working in docker for medium-large responses (VSERV-1163).

Command-Line Utility 1.16.0 (March 2, 2023)

  • We updated CLI to 1.16 in support of VirtServer 3.16.

3.14.1 (Docker Only, November 4, 2022)

  • We updated OpenSSL3 to latest version in Docker in response to CVE-2022-3602, CVE-2022-3786.

  • Please Note - Windows, Linux and Platform Independent versions remain at 3.14.0 as these are not impacted.

3.14.0 (October 24, 2022)

  • We resolved an issue where some customers using fixed licenses in private networks saw virts stopped after 20 minutes. An error message used to pop up saying that the license was not installed or expired.

  • We also supported a request to enable a download of csv and pdf file of VirtServer Audit Log with or without license.

  • We updated commons-text to 1.10 in response to CVE-2022-42889.

3.13.0 (October 10, 2022)


  • We upgraded to Java to (VSERV-1014).

  • We recommend installing VirtServer into a new folder location (rather than updating the current) and manually deleting the folder for the previous version following recent discussions with customers upgrading to VirtServer 3.13.0. We do this to enable a cleaner installation and to avoid possible issues following our recent upgrades to Java 17.0.4. This is mainly related to Linux upgrades but we recommend this approach for all other customers also.


  • If you prefer running the installer in unattended mode -q, you can configure using system properties -Dservice.install and -Dservice.autostart (VSERV-935).

    • examples: -q -Dservice.install=true will install the service, requires that the user is root. -q -Dservice.autostart=true will install the service and configure it to autostart when the operating system boots.

  • We updated Helm Chart guidelines to make it easier to manage port-numbers for virtual services easier access (VSERV-883).

Security Updates

  • We addressed the vulnerabilities that were detected within the har-java project through the inclusion of the jackson-databind-2.12.2 dependency (VSERV-844).

Command-Line Utility 1.15.0 (October 10, 2022)

  • We added help instructions when no command is specified in a CLI call (VSERV-957).

  • We added project identfier to deleteall in CLI so that virts in a project are removed (VSERV-956):

    --deleteall /path/to/projectfile or just --deleteall to delete everything.

  • We added support for zipped composite projects in CLI (VSERV-842).

    • You can send in a zipped project with -d project-file-name, or --deploy project-file-name.

    • You can send in a zipped project to --deployall.

  • We extended the capabilties of CLI to support communication with VirtServer using HTTP (where previously CLI only supported HTTPS).

  • You can activate, deactivate, and print active license information for a connected VirtServer.

  • You require Java 17 for the CLI.

3.12.1 bundled with Command Line Utility 1.14.0 (June 13, 2022)

UI Improvements

  • ‘Generate Report button’ is now deactivated when there are no virtual services deployed (VSERV-850).

  • WebUI password change and validation improved ( VSERV-255 and VSERV-815).

  • WebUI tables made easier to read (VSERV-806 and VSERV-805).

  • Popup to validate and confirm the change of Groups action (VSERV-789 and VSERV-790).

  • Notification popup behaviour improved when a user switches between the table and other screens (VSERV-394).

  • It is possible to add a Response Delay in MS to virtual service in VirtServer Web UI. This will be overwritten if the virtual service is downloaded/replaced from ReadyAPI. (VSERV-884)

Api Details

Click the image to enlarge it.

Working with copies of Virtual Services

  • It is possible to deploy several virtual services with the same name but different ports on one VirtServer (VSERV-778). These is now a new option --clone or short -c that can be added to the deploy command. This option is not allowed to be combined with --replace or short -r. That will cause an error.

    When deploying, if there already is a deployment from this virt on the server, it will do one of three things:

    • If neither --replace or --clone is present, an error will occur saying to use --replace is needed to replace. (I see now that this message could be updated to mention --clone). No changes will be performed at all.

    • If --replace is present, all deployments based on that virt will be replace. The meta data for these (like port) will stay the same.

    • If --clone is present, a new deployment will be created based on the same virt. All old deployments will stay the same.

Access Virtual Service History

  • It is possible for admins to download HAR logs from the web page (VSERV-753):


Click the image to enlarge it.

  • It is also possible for admins to send a request to an endpoint to download HAR logs (VSERV-873). There is an endpoint POST /api/v1.2/har/files that lets the user download specified har-logs:

    • Sample JSON Request

    "New JSON API-20210629_111739.har",
    "New JSON API-20210707_120708.har",
    "New JSON API-20210707_120722.har"

    • List of files can be located in the Transaction Log Screen in WebUI:

    Admin Tab

    Click the image to enlarge it.

    • Response will always return a ZIP file (even if there is only a single file).

    • Response will return all files found. If files are not available or deleted, these will not be returned.

    • Each request is logged in the Audit Log.

Request Validation Improvements

Security and Maintenance

Issues Resolved

  • Fixed issue where JMS Virtual Service could not be started when start script executed after the connection is established (VSERV-826 and RIA-19121).

  • Improved CLI issues - User used to get stuck when trying to create a user where name already exists (VSERV-393), trying to edit a user that doesn't exist (VSERV-313), makes a mistake in -pw flags when using "setservername" operation (VSERV-309) - now resolved.

  • Fixed issue where CLI failed to deploy with composite projects containing extra directories (VSERV-841).

  • Improved CLI error handling (VSERV-300 and VSERV-875).

3.11.0 (March 25, 2022)

Automocking Improvements

  • In support of SwaggerHub automocking improvements, Request Validation has been added to VirtServer. Based on the API definition document and when request validation is enabled in SwaggerHub, incoming requests to the virtual service can be validated against the schema and return valid (200) or invalid (400, 422) responses. The following table describes the expected behaviour for valid and invalid requests.


Click the image to enlarge it.

  • Added support for OAS3 / Swagger2 content negotiation, path templating, $refs for examples, and schema in OAS3 / Swagger2.


  • Groups now show an error message when a regular user tries to add or delete a tag on a Grouped virtual service where a user is not a member of the same Group.

  • Groups now allow typing usernames in the "Select Users" dropdown when configuring a new Group and seeing the list of users filtered accordingly.

  • Users can search by GroupName and only have the APIs under that GroupName show up.

  • When a virtual service is assigned to a group, 'Assigned to Group' event will be logged in the Audit logs.

  • We have improved validation and confirmation when removing a user from a Group.


  • WebUI tables only present if there is data to show or have hover state only when there is further information to show.

  • Introduced Typescript in VirtServer WebUI.

  • To increase the performance of VirtServer, the transaction log can be switched off if it is not required.

  • VirtServer log (virtserver.log file) now contains more information about the virtual service where an ERROR/WARN happened. This will assist in identifying which virtual service is affected and whether a warning or an error.

VirtServer CLI

  • VirtServer ships with the command-line utility version 1.13.0. the latest features in this version of the utility are outlined below.

  • Added --version command to VirtServer CLI.

  • Fixed CLI bug where it failed to deploy with composite projects containing extra directories.

Other Fixes

  • Fixed issue where TCP virtual service did not record routed requests when deployed in VirtServer.

  • Fixed issue where previous login session from a browser expires when the same user logs in from a different browser.

Command-Line Utility 1.13.0 (March 14, 2022)

  • The utility now supports the --version (-v) command. It prints the version of the command-line utility.

  • When you used the utility to deploy a virtual service from a composite project, the utility looked for the settings.xml file in the wrong directory. Now, it is fixed.

3.10.0 (February 1, 2022)

  • Log4j was updated to version 2.17.1.

  • Now, you can get the diagnostic report from the user interface.

  • The diagnostic report now also includes the audit log.

  • Now, when you view the audit log in the web UI, you can show only Login or Logout messages.

  • VirtServer ships with the command-line utility version 1.12.0. What’s new in this version of the utility, see below).

  • We have fixed a number of bugs.

Command-Line Utility 1.12.0 (January 31, 2022)

  • We’ve improved the messages command-line utility posts to the console output. Now, the messages contain the [ERROR] prefix for the error messages and [INFO] for all the rest messages.

  • We’ve updated exit codes. Now, in all the cases when the utility stops working unexpectedly, it returns 1.

    You may need to update your automations that rely on exit codes.
  • The new command - deployall - adds all virtual services from a project.

  • The new command - deleteall - removes all virtual services from VirtServer.

  • We've updated third-party libraries to make our product even more secure and stable.

3.9.0 (December 17, 2021)

  • The new version introduces user groups – a way of managing user permissions in VirtServer. They allow you to make certain virtual services only available to a limited group of people.

  • Log4j was updated to version 2.16.0 to mitigate the CVE-2021-44228 and CVE-2021-45046 vulnerabilities.

  • The username for LDAP connection can now be entered without domain prefix.

  • We have updated the ReadyAPI dependency to 3.20.0.

  • We have fixed a number of bugs.

3.7.3 (December 13, 2021)

  • The new version includes a fix of the Apache Log4j CVE-2021-44228 vulnerability issue and adds the -Dlog4j2.formatMsgNoLookups=true flag.

3.7.0 (September 13, 2021)

  • We updated the ReadyAPI dependency to 3.9.2.

  • VirtServer could not start when you installed it as the root user.

  • We improved the stability of the product when you run a bunch of virtual services at once.

3.6.0 (June 30, 2021)

  • Starting from 3.6.0, VirtServer uses a single database for storing all its data.

    We recommend that you make a backup of the user database located in the <user home directory>/.readyapi/virt-server folder.
  • We updated the ReadyAPI dependency to 3.8.1.

  • We improved the stability of VirtServer when it handles virtual services with the enabled autostart option.

  • We updated the web interface of VirtServer.

3.5.2 (April 6, 2021)

  • The Audit Log now contains login and logout events for users.

    This change will make the audit log unusable if you try to downgrade from 3.5.2 to an earlier version. We recommend that you make a backup of the user database located in the <user home directory>/.readyapi/virt-server folder.
  • VirtServer will try to reconnect to the floating license server when the server is restarted.

  • We fixed a bug where the request count did not update properly in the UI when a virtual service was under heavy load.

3.4.6 (October 23, 2020)

  • Now VirtServer uses the latest version of the PostgreSQL JDBC driver.

  • Since VirtServer 3.4.6, the PostgreSQL JDBC driver is always installed. The related option has been removed from the installation wizard.

  • The Web UI now uses the latest version of the React library.

To learn about previous releases, see ReadyAPI version history.

See Also

What’s New in ReadyAPI

Download VirtServer

Have you got a VirtServer license?

Get VirtServer for free

Other users:

Contact our Sales Team
Order a license

Highlight search results