Jelastic 4.0/4.1

This document is preliminary and subject to change.

In this document, you will find all of the new features, enhancements and visible changes included in the Jelastic PaaS & IaaS 4.0 and 4.1 releases:

For detailed information on using any of Jelastic’s features, please refer to the users’ documentation.

Docker® Containers Support Amendments

UI Redesign
HTTP Entry Point
Horizontal Scaling
Volumes Support
Container Redeploy (Update)
Custom Domains Support
Logs & Configurations
Automatic Ports’ Redirect
Improved Run Command Handling

UI Redesign

Several important enhancements were applied to the Docker tab interface at the topology wizard window in order to improve the visualisation and integrate support of the newly added functionality:

  • For now, the section to the left allows you to build the proper environment structure, composed with the required Docker containers, through placing them within the appropriate environment layers.

  • The Select Container frame (the former Add Container one) was integrated with the topology wizard and now by default it comprises only two tabs for image selection (through Searching over the Registry Hub or adding your Custom one), which were completely redesigned. Meanwhile, the Quick Start section became optional, so currently its availability depends on a particular hosting provider’s settings.

  • Also, for now, only one type of the Docker image can be selected within the confines of the single layer - nevertheless, any of them can be scaled horizontally just as any other Jelastic instance. And in case multiple different types of images are required, they can be added through the Extra section, which automatically expands the topology with a new layer each time you include a new Docker template to it.

  • The most common container settings were relocated to the new Configuration section at the bottom of the wizard and expanded with the new Volume option, where the mounted at the current container data storages are listed. Also, these configurations can be quickly accessed under the Additionally list next to the appropriate image layer at the dashboard’s environment list.

More info

Back to the list of Docker Amendments

HTTP Entry Point

Starting with the Jelastic 4.0 version, each Docker-based environment is provided with its own entry point (i.e. domain name). Thus, for now not just separate containers can be accessed (as previously, via the direct link or external IP attached), but a whole environment (via the embedded Shared Load Balancer) as well.

So, if it is required to get the domain name for the environment with Docker containers, an image should be added to its App. Servers and/or Balancing layer (otherwise, i.e. if you don’t fill any of them, the domain won’t be attached). Subsequently, upon navigating to the bound address, a Docker image from the corresponding section will be opened.

Such an implementation ensures the additional support of some of useful and commonly demanded features - for example, it allows to:

In such a way, for now you can treat the Docker-based environments in the most beneficial and familiar way, just like any others, i.e. composed with standard stacks ones.

Back to the list of Docker Amendments

Horizontal Scaling

In order to extend the Docker-based environments’ functionality and improve the experience while their usage, the current 4.0 release brings the support of the horizontal scaling feature for Docker containers. So, for now, any of them can be multiplied within the confines of the corresponding environment layer. Same as for other wizard tabs, this can be easily applied via the central section of the Environment Wizard using the +/- buttons.

The implemented scaling workflow is also the similar, i.e.: for each newly added container, depending on the template’s type, either the very initial master node will be duplicated (for application servers and load-balancers) or a new one will be created (for all of the rest of stacks). In case of decreasing the amount of containers for such a scaled instance, the last added will be removed.

Back to the list of Docker Amendments

Volumes Support

The new 4.0 Jelastic version includes the support of Docker volumes - the dedicated mounted locations, intended to persist the container’s data independently of the application lifecycle. This allows to perform different operations with container (e.g. redeploy it with another tag version) without loosing the data it already contains.

Implementing this functionality resulted in addition of the new same-named section within the Docker container settings frame, where the predefined volumes (if such were declared within the corresponding image manifest) are listed by default. Beside that, you can easily add custom volumes through specifying the path to the location it should be mounted at. Physically, each such declared storage is placed inside the dedicated /volumes directory within the container’s root. Herewith, any custom volume can be removed at any time upon it becomes unnecessary, while the predefined ones are considered as obligatory ones and thus can’t be deleted.

In order to find out the details on Docker volumes management, please refer to the corresponding guide.

More info

Back to the list of Docker Amendments

Container Redeploy (Update)

The majority of Docker templates are rapidly developed, thus, evolving over the time, the new tags (versions) of the image are continuously presented. And here comes the problem of upgrading the existing Dockerized applications and services up to the desired releases without losing the existing configurations.

In the present Jelastic Platform release such mechanism was implemented, allowing you to redeploy any of the already created Docker-based containers with another tag applied. During such an operation, all the inherent configurations and settings (including custom variables and linking between nodes) will be saved, thus you won’t need to redefine any of them. Surely, all the data stored within the volumes won’t be affected too.

This option can be called through clicking the Redeploy container(s) button within the template’s context menu (which is shown upon hovering over a particular instance or layer) at the dashboard or through the pencil icon next to the current tag version at the Change environment topology window. Within the appeared redeployment frame, you can select the desired image version for the chosen container(s) to be updated with, and, if operating with multiple nodes, to enable the Sequential deployment switcher. In the latter case, containers within the selected layer will be updated sequentially, one by one, allowing the corresponding service remain available during this procedure. Otherwise, all of them will be redeployed at once, causing the temporary downtime of your app.

Right after the process is finished, you’ll see the success notification at the top-right corner of the dashboard with the Show Logs button. Upon clicking on it, the corresponding redeploy log tab will appear, with the complete information on the performed actions and their duration for all of the containers displayed.

More info

Back to the list of Docker Amendments

Custom Domains Support

The newly implemented ability to operate an environment, that is composed of a set of Docker containers, via a single HTTP entry point (i.e. the common domain name attached) can be complemented by binding a custom domain name to it for getting even better usage experience. This operation can be accomplished in a matter of minutes right through the dashboard, in a completely similar way as for any other environment type - i.e. by means of the dedicated Custom Domains section of the environment’s Settings. As a result, you get the possibility to run and poses your Dockerized apps as a production-ready solution.

More info

Back to the list of Docker Amendments

Logs & Configurations

With an aim to simplify the Docker containers management, within the current Jelastic 4.0 release we’ve adjusted the following functionality to be available directly through the dashboard:

  • for now you can access all the data and configuration files inside your container through pressing the appropriate Config button for the required node/group of nodes. Herewith, you are provided with the full root access for the comprised files’ edition, just like when entering your container via SSH.
  • the most crucial information on your container’s state is now available within Logs - the corresponding tab can be opened using the same-named button next to the required container(s). Also, viewing this data is automatically proposed after any container is created (with the Show Logs button within the appropriate dashboard notification). Herewith, though the list of available log files can vary depending on a particular image settings, the run.log file will be automatically opened first (if present), as usually it is intended to store the information on the appeared errors.

More info

Back to the list of Docker Amendments

Automatic Ports’ Redirect

Depending on a particular Docker image specifics, it can be run on some custom port so that application inside can’t be accessed without the Public IP attached or a special manual adjustment performed. In order to get rid of such an inconvenience, starting with the 4.0 platform version, Jelastic automates these configurations and adds the required redirect to the iptables list by itself, so that the corresponding application becomes available over the embedded Shared Load-Balancer without any manual interventions required.

In order to implement such a scenario, a special script was written and integrated to be executed after each Docker container launch. It tracks the ports, that are listened by application on the TCP level at the container start up and separates the ones, which are commonly used by standard services (e.g. SSH, mail, databases, etc). After that, all of the incoming requests are redirected to the remaining port (or, in case several of them have left, the first one in the list is used).

In such a way, an application becomes available through the shared balancer just after the deployment is finished.

More info

Back to the list of Docker Amendments

Improved Run Command Handling

Traditionally, Docker containers use CMD instruction in order to set the command to be executed by default on each startup. Usually, it is run through the /bin/sh -c’ entrypoint, so if CMD (or Run Command, as it’s named at our dashboard) is set, for example, to ‘bash’, the actually executed string is ‘/bin/sh -c bash’. However, for some specific purposes, it may be required to change the default entrypoint and substitute it with some custom executor to run the given command.

For now, such procedure can be handled using the Entry Point field, which was added to the Run Config section of the Docker container settings frame alongside the Run Command one. Specifying the desired custom values within these parameters allows to configure any required startup operation. Additionally, upon editing these settings, a special Reset to default button will appear, so you’ll be always able to negate any undesired changes, returning their initial state.

More info

Back to the list of Docker Amendments

Back to the list of Features

Jelastic CLI Client

With an aim to simplify the account management for developers, we are glad to present the Jelastic-dedicated command-line interface (CLI) client, designed to easily handle almost all of the operations, initially available only through the dashboard, remotely. Also, it allows you to monitor, control and automate your application’s lifecycle by writing and applying the corresponding scripts and, in such a way, extend the default platform possibilities.

The CLI client for Jelastic can be obtained with just a single line of code, that should be executed via your terminal:

curl -s | bash

This command runs a simple script, which will download and install the client to the dedicated jelastic folder at your home directory. Next, it will add the required record to the PATH variable within the .bash_profile file for the Jelastic methods to be easily executable. The structure of CLI folders and scripts inside represents the hierarchy of the Jelastic API, that results in a complete similarity of the corresponding working process. In such a way, the API-familiar users can get used to the client much more faster, while others are able to learn two ways of account management at a time.

On the first method’s call you’ll be requested for the desired platform’s URL (in the http://app.{hoster_domain} format) and your account credentials. Consequently, when the authentication is passed successfully, the information on your actual user session will be saved to the .config/ file. If it’s required to change the currently used platform or account, the corresponding ~/jelastic/users/authentication/signin method should be called with the new login information as parameters.

More info

Back to the list of Features

CentOS 7 Support

Jelastic always tries to keep up with the most current and stable stack versions, therefore, in the present release we are glad to introduce you the major update of the Jelastic basic OS template for all containers to the latest CentOS 7 version.

Generally, the most noticeable amendment in the seventh release compared to the previous sixth one is a new initialization daemon - the default SystemV Init startup scripts were replaced with the more concurrent Systemd (System Management Daemon) solution. Init was the first commercial solution and currently is the most popular one, while the systemd is more recent and was designed to overcome the known shortcomings. For example, it removes the serial processes flow structure (i.e. when a new task starts only after the last one was successfully finished and loaded into the memory), which often results in delays and long booting time. Instead, systemd starts all processes in parallel, improving the processing speed and computational power.

To learn the rest of new distribution’s specifics, refer to the official web site, where the complete list of the performed changes with their detailed descriptions can be found.

In order to implement the latest version of CentOS at the Jelastic Platform, the new centos-jelastic-7 operating system template was created (based on the similar one from Odin, but, obviously, with the needed stuff included only). As a result, all the RPMs for software stacks templates were rebuilt (except the PostgreSQL 8 database, which was removed, because it’s no longer supported under CentOS 7).

Surely, the CentOS VPS container template was updated to the latest 7th version too. Just as before, you can get the fully isolated and secured virtual private server through the VPS topology section at the environment wizard. In addition, to improve its usage experience while its usage and simplify the management, we’ve added the ability to configure VPS directly through the dashboard’s Configuration Manager (just as it could be previously done for the rest of stacks, but with the full root permissions granted) and view the information on its operability via Logs.

More info

Back to the list of Features

Setting Custom Firewall Rules

In some specific cases, it may be required for the special firewall restrictions (i.e. which are not declared within default container settings) to be set within your nodes. Previously, the iptables rules’ management could be performed at the hosting provider’s side only, but starting with the present release, you’ve got the possibility to apply the desired changes for the newly created containers by yourself.

Note that for this operation to be performed, you need to ensure the appropriate container’s firewall is already enabled. For that, access its /etc/jelastic/metainf.conf file via SSH, where the FIREWALL_ENABLED=1 string should be present. Otherwise, send the corresponding request to your hosting provider and re-create a container after it’s satisfied.

Such custom ip-rules should be declared and stored within special dedicated file, named iptables-custom and located within the /etc/sysconfig directory. So, the flow is the following:

  • access the required container via SSH and open the above mentioned file
  • declare the required rules using the iptables-save tool’s format, for example:

    -I INPUT 1 -j ACCEPT -s


  • enable custom firewall with the next command:

    sudo /usr/bin/jem firewall fwstart

The currently applied rules can be checked using the following command:

sudo /usr/bin/jem firewall list [ filter | nat | mangle ] [iptables options]

In such a way, you can make and apply changes to your containers’ firewall settings without the additional assistance from hoster's side.

More info

Back to the list of Improvements

PageSpeed Module for Apache

Striving to give you the best possible experience, Jelastic continues to integrate the time-tested and proven to be worthy solutions as the default platform opportunities. In the current release it’s a PageSpeed module, developed by Google. It became really popular due to the noticeable performance boost it ensures by means of numerous in-build optimization filters.

Being added to the default Jelastic Apache build, this module is disabled by default, but can be easily activated. For that, you just need to navigate to the conf.d > pagespeed.conf file using the embedded Configuration Manager for your Apache server, and uncomment the following lines (the appropriate module version will be chosen automatically based on the currently used server version):

     LoadModule pagespeed_module /usr/lib64/httpd/modules/

     LoadModule pagespeed_module /usr/lib64/httpd/modules/

After these changes are saved and the server is restarted, the module will be activated and start to work, reducing the incoming requests’ processing latency.

Back to the list of Improvements

UX Improvements

Installation Widgets Improved Usability
Billing History Detalization
Automatic Export Disabling
Marketplace UI Changes
ZDT Deployment Amendments
Auto-resolve Conflicts Logging
Maven Plugin Update 

Installation Widgets Improved Usability

Jelastic one-click installation widgets represent an extremely easy and effective way of app’s distribution. Within the current release, the general widgets concept undergone some notable changes in order to match the newly appeared requirements for their functionality, namely:

  • Due to the greatly enlarged number of alternative Jelastic installations, hosted by various service providers in close locations, the geoIP method, previously used for the automatic selection of the most suitable platform, appear not to always bring the desired result. Thus, we’ve added a special configuration pane, which is displayed at the bottom of the widget upon hovering over it. It contains an expandable list of all of the available Jelastic service providers, with their logos, countries and platform versions. Just as before, the geographically closest one will be proposed by default, while installations without the registration possibility are automatically excluded from this list.

  • Using the special URL button at the right part of the new widget, it became possible to copy the direct link to the app manifest. Subsequently, if already having the account, you can easily deploy the corresponding application right through the dashboard by specifying this URL within the Import frame or through executing the appropriate API method, i.e. by adding link to the platform address in the following format:


  • The last enhancement is the confirmation dialog, which appears just before the installation is started in both of the above described cases. It allows not only to cancel the deployment, but also to set the desired environment name and choose the preferable environment region.

In order to define whether to use the new type of widget, the data-hoster-select parameter is used (1 - to enable, 0 - to disable). In addition, it could be supplemented with the data-keys option to limitate the proposed hosting Platforms list, so the only declared here providers will be shown.

Note: New widget currently works with the modern” data-theme parameter only.

Back to the list of UX Improvements

Billing History Detalization

In order to provide more complete information on account charges, in the current 4.0 release we’ve added the billing history detalization based on the separate nodes consumption, rather than on the group’s of the same-typed instances. This was driven by the reason that nodes within an environment layer oftenly could be loaded not equally, thus their costs can differ.

Due to this, for now the billing history is shown separately for each node in the environment by default. However, if such a detalization is not required, it can be disabled with the corresponding Group by node switcher, appeared within the Billing history tab settings.

More info

Back to the list of UX Improvements

Automatic Export Disabling

Jelastic Environment Export and Import feature is a great solution for transferring applications between different Platform installations. However, currently this opportunity is not provided for the containers of the certain types (namely, Docker- and Windows-based ones), thus the export option was automatically disabled for the environments with such nodes comprised.

So, for now, when you navigate to the Settings tab for any of your running environments, the presence of the available for transfer elements is automatically checked. And if the result shows, that there isn’t a single such node, the Export section’s options become dimmed with the corresponding warning message (highlighted in red for the better visibility) shown above to mark this feature unavailability.

Back to the list of UX Improvements

Marketplace UI Changes

In the current Platform update, the Marketplace dashboard section has received a few minor improvements, intended to make all the provided functionality easily accessible and convenient for usage:

  • first of all, the corresponding Marketplace drop-down list at the top pane of the dashboard was removed, leaving only the same-named button. When clicked on, it leads to the appropriate Marketplace tab with the Apps expandable section (formerly named as Applications) active. Just as before, it contains the categorized list of the applications, that were preconfigured in the most beneficial way specially for Jelastic and can be installed in a few clicks.
  • a bit lower, the new Add-on section appeared. Obviously, all the add-on packages can be found here, which makes them much more easier to be found and implemented.
  • the last section, which provides the ability to add the required Docker template to an environment, was renamed to Containers, while providing the same functionality as before.

More info

Back to the list of UX Improvements

ZDT Deployment Amendments

The recently added Zero DownTime Deployment feature for PHP apps continues to being developed and polished. So in the confines of the 4.0 release it got two major updates:

  • improved VCS autoupdate handling - the default ZDT scenario for deployment from VCS using the autoupdate option makes the periodical redeployment operations and ensures the application availability during them. But in case the iteration interval is set rather low, the frequent updates may badly affect the server capabilities due to the high I/O load. Thus, the method behaviour was improved and for now it performs the preliminary changes check up, comparing the current project’s revision ID with the previous one (stored in the project properties). If there is a difference, which means some update was committed to the repository, the redeployment will be called; otherwise,  ZDT won’t perform any operations to save your resources.

  • logs for ZDT operations - the list of logs files for PHP application servers (both Apache and NGINX) was extended with the additional deploy section. It contains the detailed data on all of the deployment-connected operations, including the ones, performed by ZDT module. Here you can explore the information on permission edits, context, directories and files modifications, symlink switching, ownership changes, overall deployment results, etc. Note that this logs section isn’t shown within the list by default, but will be instantly displayed upon any record is written down (i.e. after a single ZDT deployment is performed).

Back to the list of UX Improvements

Auto-resolve Conflicts Logging

The auto-resolve conflicts option, which is used for the VCS deployment type and represents an analogue of the git reset --hard command, is intended to prevent the occurrence of conflicts while projects updates. In case any such issue arises, the contradictory file is changed according to its repository version, discarding the locally made changes.

With an aim to clarify how this option works and, generally, to show the complete information on the handled VCS deployments (both manual and automatic ones), in the current Jelastic release the corresponding data started to be stored within the newly added vcs_autoresolve log file. Namely, it provides the information on the most recent repository revision (i.e. ID of the lastly committed repo modification with the corresponding comment) and on all crucial actions, performed in order to solve the appeared encounters. All of the listed records are followed with the appropriate timestamps.

Note that this logs section appears only after any record is written to it, i.e. upon the deployment operation with the auto-resolve conflicts option enabled was run.

Back to the list of UX Improvements

Maven Plugin Update

Maven is a popular software tool, that allows to build and manage Java-powered projects. Being tightly integrated to the Jelastic Platform by means of the specially developed external plugin, it can be easily added to any of your Java projects through the pom.xml configuration file. Performing this gives you the opportunity to deploy this project to your Cloud environment just with a single command, executed via the local terminal.

Within the confines of the present 4.0 release, the Jelastic plugin for Maven got a little update, aimed to improve its usability. According to it, only the five last project builds, uploaded by the plugin to the Jelastic Deployment Manager, are stored. So, when the sixth such file is added, the oldest one is automatically removed. Herewith, this operation does not influence the packages, that were added manually or with the help of any other tool. Such an approach results in avoiding the mess within the list of the available packages, simultaneously releasing the space these unrequired builds consume, and, therefore, reducing the spends on disk usage.

More info

Back to the list of UX Improvements

Back to the list of Improvements

PostgreSQL Package for Python

In order to improve the Jelastic Python cartridge interaction with the PostgreSQL DB and to solve the problems with the pg_config missing error, the list of its default RPM packages was extended with the new postgresql-devel one. In addition, this ensures the support of some additional tools, e.g. psycopg - the most popular adapter for the Python programming language and PostgreSQL database joint work.

The included package contains the basic DB client, some manual pages with the supported by PostgreSQL commands listed, and a number of utility programs for the proper database work maintenance. The full list of files and their descriptions can be found at the official database documentation.

Back to the list of Improvements

Redirects’ Autoresolve

The Jelastic unpack module, which is implicated in various platform processes (from the environments’ import to a simple curl commands handling), has received a slight update in the current 4.0 Cloud Platform release - support of the -L (--location) flag, which is now enabled by default. This means that upon receiving the report from the destination server, which says that the required page was moved to a different host, the request will be tried again for this new location. If executing the appropriate command manually, the amount of such redirects can be limited by the corresponding --max-redirs option.

In case the request contains the authentication data, the credentials will be provided for the initial host only. This won’t allow the malefactors to intercept your login and password information, providing a sufficient level of security.

Back to the list of Improvements

Engine Versions Update (4.1)

The regular programming languages engines’ renovation, provided by Jelastic within each Platform release, brought the following updates this time:

  • The greatest leap was done for the NodeJS app server, as for now it could be run over the 4.2 version (the previously available one was 0.12). Such a versions gap was caused by the reason that the 1.x - 3.x releases have been implemented as a part of the io.js fork only, while being eventually merged within the unified 4th release. The new available features and notable changes of the last Node.js version can be explored here.

  • Another newly added engine version is Python 3.5, which is now distributed alongside the legacy ones. It delivers a bunch of new features, as well as some security improvements and bug fixes - for the precise details, please, refer to the official documentation.

  • One more update covers the usage of the most recent Ruby 2.2 engine. The exact new version is 2.2.3, which replaced the preceding 2.2.2 one.

As usual, the complete list of the software stacks-related changes, included to the current Jelastic release, can be viewed within the corresponding section.

Back to the list of Improvements

Software Stack Versions

The component templates versions have been updated to their latest versions since the previous release:

StackJelastic 4.0Jelastic 4.1
Tomcat 66.0.436.0.43
Tomcat 77.0.627.0.62
Java 61.6.0_45 1.6.0_45
Java 71.7.0_791.7.0_79
Java 81.8.0_451.8.0_45
MariaDB5.5.42 / / 10.0.17
MySQL5.6.24 / / 5.7.7
PostgreSQL 8incompatibleincompatible
Centos 67.17.1
NGINX Ruby1.
Python 3.5-3.5.0
Node.js0.10 / 0.120.10 / 0.12
Node.js 4-4.2

Back to the list of Improvements

Bug Fixes

In the tables below, you can see the list of bug fixes in Jelastic PaaS 4.0 and 4.1:

Jelastic 4.0
JE-13344The embedded MongoDB backup script creates an empty archive if the authentication fails for server version >=2.6
JE-19954Load alerts for the removed nodes remain active
JE-20460Unable to access the data within dashboard tabs after downloading the Custom SSL certificate files from dashboard
JE-20471The “Unable to connect to the database server” error occurs while opening the cloned\imported environment with PowerDNS
JE-20487Incorrect subject of the russian email notification about the automated NGINX-balancer node addition to the WordPress cluster package
JE-21018Incorrect network settings (internal IP) for the migrated Docker-based server with external IP
JE-21097Long delay before starting download the project build over 100 MB, uploaded to the dashboard via Maven plugin
JE-21113The Build&Deploy Maven operation fails for the cyrillic-named environments
JE-21123Incorrect error message if no free disk space left in a container during the deployment process
JE-21175Ability to set odd number of nodes within the auto-horizontal scaling settings for app server with High-Availability enabled
JE-21349Wrong RDP link for the Windows 2012 node with external IP enabled
JE-21381The access permissions for the main nodes’ configuration files are reset after the appropriate service restart via SSH
JE-21498Inability to access the MongoDB 3.0 admin panel with new credentials after resetting the password
JE-21573Absence of the Task Manager records for the linking and setting environment variables actions, applied to a Docker containers
JE-21574The automatic redirection of listened ports to the 80th resolver's port does not work properly for Node.js
JE-21731The scroll lock option does not work for the log files with more than two pages of records
JE-21811Building project via Maven with the auto-update interval set to 1 minute isn’t started within 5 minutes for the environment in default region due to the wrong resolver configuration
JE-21886Wrong validation for the remote VCS project link
JE-21889Missed FTP addon installer for the MongoDB 2.6 node
JE-21909The Dockerized services could not be run if the appropriate container's start script does not refer to "/bin:/usr/bin:/sbin:/usr/sbin"
JE-21962Wrong parsing of the Docker image environment variables' values with white spaces
JE-21971The Task Manager records are duplicated/erased because of the repetitive reading log action, run due to the logs’ auto-refresh option enabled
JE-21983The started with "ROOT" folders are removed during the ZDT-handled project redeployment to the ROOT context with the ZDT option already disabled
JE-22030The “DNS can not resolve the hostname” exception is hand out during starting/stopping the GlassFish 4 service via SSH
JE-22059The “Can not detect OS version” error occurs while trying to deploy the fedora:latest Docker image
JE-22060Unable to establish SSH connection to the Docker container with the Fedora of the 20/21 version deployed
JE-22083Old alias name for the imported environment after its cloning
JE-22123Unable to deploy the dockerized Debian image due to the “Can not detect OS version” error
JE-22339The previously deployed contexts within a single environment become inactive after refreshing the dashboard and deploying one more app

Jelastic 4.1
An error occurs while trying to clone environment with two GlassFish 3 servers, located at the non-default environment region
The logs’ preview for Docker containers is not cleaned up after switching to another file
Names of the uploaded to Docker or VPS container files with the $” symbol are truncated
The “\” character is added to the file name with the “ ' ” symbol while uploading it to Docker or VPS container
An error occurs while trying to create the file with “ ’ ” or “ ` ” symbol in the name inside a Docker or VPS container
Unhandled error for operations’ failure due to the user-performed renaming of the main system Docker directories or files
The Container is not running error appears while trying to restart a Docker node during its log tab is loading
Unhandled errors for the Renaming is not permitted and Can’t execute command at a non-running container exceptions at Docker and VPS containers
Ability to enable the ZDT option while deployment to the non-ROOT context
The import operation fails if the uploaded manifest doesn’t contain the "categories":"export" parameter
An error occurs while trying to delete the Docker’s log file during its auto-refreshing
File with special symbols in name remains present in Docker container after being deleted, whilst is not shown in the file manager
One of the two required configuration files at the NGINX load balancer’s conf folder is missed depending on the chosen environment topology
Presence of the Config and Log buttons for the Windows-based VPS nodes
Files of the project, deployed to the Tomcat 8 or Glassfish 4 app servers, are missed during the export/import operation
An error occurs while trying to redeploy a Docker container with white space in the volume’s name
The same log file can’t be viewed at different environments simultaneously
Improper validation of the restrictedPaths property within Docker container manifest causes crashing while some images’ creation
Inability to connect to legacy environment via FTP after installing the appropriate add-on to it
The newly created files and folders within IIS8 nodes in different environments of the same user are shared
Absence of the Show Logs button at the appropriate pop-up notification after deploying a Docker image via Marketplace
Path hints are not displayed for the newly created items within file manager for Docker/VPS containers
Absence of the directory name length validation for Docker and VPS containers
Unhandled exception while trying to view logs for the stopped Docker-based environment
Missed mysql-community-libs-compat default package for the MySQL 5.7 server
The Remove button remains enabled in case of selecting multi records within Docker container settings frame
Empty resolv.conf file for the deployed unigeocloud/ubuntu-vnc-novnc-qgis210 Docker image
Unhandled error while trying to access the renamed binary file via Docker file manager
An error occurs while trying to rename several folders, that were created simultaneously
An exception appears while trying to perform any action with Docker container folders via file manager and refreshing the root directories tree at the same time
Unhandled error while uploading a file to Docker container via the embedded file manager if this operation is not permitted
The uppercase characters in Docker volume name are turned to lowercase while its addition
Unhandled error while trying to rename log file at the Docker-based container
Number of workers is not equal to the number of physical cores for the Apache-Python node
The password expiration flag is not reset after its recovering for the MySQL 5.7 node