Backendless Pro is a build of the Backendless Platform which provides a self-managed installation of the product. The product is available for a variety of operating systems and the cloud environments. Once installed, the product provides the complete Backendless Platform functionality.


Backendless Pro does not have any of the limits of the Cloud Edition of the product. In fact, all limits are configurable to match the demands of your application. The product architecture consists of multiple components which can run on a single computer or a virtual machine. However, it is recommended to plan for high availability. See the Deployment Scenarios section for more details.


The standard installation of Backendless Pro consists of the components shown in the diagram below:


Web Server - an Apache web server provides the function of processing the API and management console requests.
Application server - implements core services, manages and schedules custom business logic execution.
Persistent Storage - stores application data and application analytics.
Redis - the server is used for caching purposes, inter-process data exchange and shared configuration. Additionally Redis is used as an intermediary storage for scheduling autonomous tasks executed by Task Managers and Code Runners.
Task Manager - Backendless Task Manager is responsible for autonomous task execution for parallel/distributed processing.
CodeRunner - a container process enabling execution of custom business logic.


The Backendless Pro distribution is available through native installers for Linux, Mac OS and Windows operating system.
The installers can be downloaded from the Backendless website.


Third Party Components

The Backendless Pro stack ships with the following third party components:

Apache 2.4.23
MariaDB 10.1.14
MongoDB 2.6.12
Redis 3.2.1
JDK 1.8.0_101


A Backendless Pro installation requires:

Intel x86 or compatible processor
Minimum of 16384 MB RAM.
Minimum of 8 GB hard drive space
TCP/IP protocol support
Compatible operating systems:
 - An x86 or x64 Linux operating system.
 - An OS X operating system.
 - Windows Server 2012 or higher.

Native Installers

The downloaded file name will have the following pattern (X.Y.Z denotes the version number):





Mac OS:



On Linux, you will need to give it executable permissions before you can run the installer:

chmod 755 backendless-3.5.0-linux-x64-installer.run

Installation Modes

The installer supports the following installation modes:

Graphical mode (by default).
X-Window: It will be started when the GTK mode is not available or can be explicitly requested with the "--mode xwindow" command line switch.
Command line: This installation mode is started by default when a graphical environment is not available or by passing the "--mode text" command line option to the installer.
Unattended Installation: It is possible to perform unattended or silent installations using the "--mode unattended" command line option.


For all modes, you can check all installer options by passing the "--help" command line option to the installer. See the Installer Arguments section for a complete list of supported command line arguments.


Installer Options

The installation program supports the following command line options:



Default value

Available arguments


Display the list of valid options


Display product information

--unattendedmodeui <unattendedmodeui> 

Unattended Mode UI


none minimal minimalWithDialogs

--optionfile <optionfile>

Installation option file

--debuglevel <debuglevel>     

 Debug information level of verbosity


0 1 2 3 4

--mode <mode>   

Installation mode


qt gtk xwindow text unattended

--debugtrace <debugtrace> 

Debug filename

--installer-language <installer-language>

Language selection


sq ar es_AR az eu pt_BR bg ca hr cs da nl en et fi fr de el he hu id it ja kk ko lv lt no fa pl pt ro ru sr zh_CN sk sl es sv th zh_TW tr tk va vi cy

--prefix <prefix> 

Installation directory

--base_user_name <base_user_name> 

Your real name

User Name

--base_mail <base_mail> 

Your Email Address


--base_user <base_user>

User name to create for login to Backendless console


--base_password <base_password>

Password to create for login to Backendless console

--apache_server_port <apache_server_port>

Apache web server HTTP Port

80 or 8080 - depending on your permissions

--apache_server_ssl_port <apache_server_ssl_port>

Apache web server HTTPS/SSL port

443 or 8443 - depending on your permissions

--mysql_port <mysql_port>

Port to install MariaDB on


--mysql_password <mysql_password>

MariaDB Server root password

--mysql_database_name <mysql_database_name> 

Name of the database to assign for the Backendless installation


--mysql_database_username <mysql_database_username> 

DB User Name


--mysql_database_password <mysql_database_password> 

DB User Password

--redis_port <redis_port>     

Port to assign to the Redis installation


--mongodb_port <mongodb_port> 

MongoDB Server port


--mongodb_password <mongodb_password>   

MongoDB Server root password

--smtp_email_provider <smtp_email_provider> 

Default email provider:


gmail custom

--smtp_enable <smtp_enable> 

Do you want to configure mail support?


--smtp_user <smtp_user>   

SMTP account username

--smtp_password <smtp_password>

SMTP account password

--smtp_host <smtp_host>

SMTP server hostname

--smtp_port <smtp_port> 

SMTP server port


--smtp_protocol <smtp_protocol>

SMTP server connection security protocol


none ssl tls

--play_port <play_port> 

Play! server port


--appName <appName> 

Name of the Backendless app to create


--backendless_addr <backendless_addr>   

Address/hostname where Backendless installation is going to be available at

--backendless_debug_redis_port <backendless_debug_redis_port>

Backendless Debug CodeRunner Redis port


Quick Reference

The table below provides a summary of the default settings and some important paths for your Backendless Pro installation:

The <installdir> in this section of the documentation identifies the installation directory of Backendless. For the installations created with Native Installers, it is a directory selected during the installation.



Log file path


Apache HTTP port

80 or 8080

Apache HTTPS port

443 or 8443

MariaDB port


Redis port


Redis port for CodeRunner Debugger


MongoDB port



Server Address

Backendless must be configured to respond for a specific domain name or IP address. Backendless installer provides a way to specify the address during the installation process. If the domain name or the address changes, the installation must be reconfigured per the instructions below:


1. Identify the Backendless installation directory - it is a directory set during the installation process.
2. Run the following command to update the domain name/IP address for your Backendless installation:

sudo <installdir>/apps/backendless/bnconfig --machine_hostname NEW_DOMAIN_OR_IP_ADDRESS

for example:

sudo /home/dev/backendless/apps/backendless/bnconfig --machine_hostname


Email Settings

Backendless sends out emails for various administrative tasks such as developer registration, inviting a developer to work on the app or changing developer password. Additionally, the API to send email requires mail server configuration. A Backendless Pro installation must be configured with settings for an email account you would like Backendless to use.

The <installdir> in this section of the documentation identifies the installation directory of Backendless. For the installations created with Native Installers, it is a directory selected during the installation.

To configure email manually, follow the steps below:

1. Edit the <installdir>/apps/backendless/htdocs/conf/mail.properties file and modify the following configuration properties:
config.mail.settings.smtp.server = smtp-server-domain-name-or-ip-address
config.mail.settings.smtp.port = smtp-server-port-number
config.mail.settings.userid = email-address
config.mail.settings.password = password-64base-encoded
config.mail.settings.protocol = TLS or SSL
config.mail.settings.send.from = name-of-who-sends-the-email
config.mail.settings.send.from-email = email-address-in-the-form-field
config.mail.settings.send.timeout = 10
config.mail.settings.connection.timeout = 10

The timeout properties are values in seconds.
2. Update the example values above for your SMTP server. Note that the user password value  must be Base64-encoded.
3. Restart all services for the changes to take effect.

Configuration settings from mail.properties become default mail settings for any Backendless application created in the Backendless Pro installation.


SSL Support

The <installdir> in this section of the documentation denotes the installation directory of Backendless. The instructions below assume that you are using a custom domain name for your Backendless installation.

Once you obtain the certificate and certificate key files, you will need to update your server to use them.  Make a note of the default locations of the configuration and certificate files:

Current application URL: http://[domain-or-IP-address]:8080
Apache configuration file <installdir>/apache2/conf/bitnami/bitnami.conf
Certificate file <installdir>/apache2/conf/server.crt
Certificate key file <installdir>/apache2/conf/server.key
CA certificate bundle file (if present) <installdir>/apache2/conf/server-ca.crt


To activate SSL support:

1. Copy your SSL certificate and certificate key file to the locations specified above.

If you use different names for your certificate and key files, you should reconfigure the SSLCertificateFile and SSLCertificateKeyFile directives in the corresponding Apache configuration file to reflect the correct file names.
In all cases, you should update your Apache configuration file and in the default VirtualHost block for the SSL host, ensure that the ServerName directive is set to your custom domain name.

2. If your certificate authority has also provided you with a PEM-encoded Certificate Authority (CA) bundle, you must copy it to the correct location identified above. Then, modify the Apache configuration file to include the following line below the SSLCertificateKeyFile directive. Choose the correct directive based on your scenario and Apache version:

Apache version

Directive to include

is or greater than 2.4.8

SSLCACertificateFile "<installdir>/apache2/conf/server-ca.crt"

less than 2.4.8

SSLCertificateChainFile "<installdir>/apache2/conf/server-ca.crt"

3. Once you have copied all the server certificate files, you may make them readable by the root user only with the following commands:

sudo chown user:user <installdir>/apache2/conf/server*
sudo chown user:user <installdir>/apache2/conf/server*

4. Restart the Apache server:

sudo <installdir>/ctlscript.sh restart apache

5. You should now be able to access your application using an HTTPS URL.


Two or more installations of Backendless can be configured to work as one thus increasing transactional throughput, scalability and reliability. The instructions below describe the process of configuring two machines to form a Backendless cluster. Configuration of additional (third, fourth, etc) machines must follow the same process.

The <installdir> in this section of the documentation identifies the installation directory of Backendless. For the installations created with Native Installers, it is a directory selected during the installation.


All references to {machine1_ip} in the instructions below identify the first machine in your cluster. However, to achieve a configuration without  a single point of failure, it is recommended that the value of {machine1_ip} would be the address of your load balancer. In a properly configured environment the load balancer can detect failures of individual machines and properly re-route service/console requests. Additionally, a configuration without a single point of failure must include replication between the databases and the redis nodes.


As a result of the configuration changes below, your cluster would look as shown in the following diagram:



On machine1:

1. Open file <installdir>/apps/backendless/conf/httpd-app.conf in a text editor.
2. Add the following section:
<Proxy balancer://mycluster>
    # WebHead1
    BalancerMember http://[machine1_ip]:9000

    # WebHead2
    BalancerMember http://[machine1_ip]:9000

    ProxySet lbmethod=byrequests
3. In section <Location /api > change
ProxyPass http://{your_server_ip}:9000
ProxyPass balancer://mycluster
4. Restart all services

If any of the port numbers were modified during the installation of Backendless Pro on machine 1 and machine 2, it is important to modify these port values in the configuration as well. The instructions below assume that both installations (machine 1 and machine 2) are configured to run individual Backendless components on the same ports.

On machine2:

1. Open file <installdir>/apps/backendless/modules/java_coderunner/bin/runner.properties in a text editor.
2. Change all occurrences of {your_server_ip} and localhost to {machine1_ip}.These should be in the system.server.url and system.redis.master.host variables.
3. Change system.redis.master.port and system.redis.master.password to the machine1 values.
4. Add {machine1_ip} to the enteprise.allowedHosts list, so that it will look like:
enterprise.allowedHosts = localhost,\,\
5. Change all occurrences of {your_server_ip} and localhost to {machine1_ip} in the following files:
<installdir>/apps/backendless/htdocs/conf/console.properties (change backendless.com to the {machine1_ip} address).
6. In <installdir>/apps/backendless/htdocs/conf/connection.properties set the following properties to contain the values from the same file on machine1:
7. In <installdir>/apps/backendless/htdocs/conf/mongo.properties set the following properties to contain the values from the same file on machine1:
8. In <installdir>/apps/backendless/htdocs/conf/redis.properties change the values for all properties ending with ".password" to the value from the same file on machine1.
9. Start only play, taskmanager and coderunner services


Now you can work with the console on http://{machine1_ip}:8080.

External Data Hosts

Backendless Pro can be configured with MariaDB, Redis and MongoDB running on an external host. Consider the diagram below:


The following configuration changes must be made in order to achieve the configuration shown above:


External MariaDB

1. Configure your MariaDB server by running the following mysql command:

mysql> set global log_bin_trust_function_creators = 1;

2. Increase max_connections variable by running the following commands:

mysql> select @@max_connections;
mysql> set global max_connections = 200;
mysql> select @@max_connections;

3. The Backendless database in a MariaDB server must be created by running the following script:
4. Open the following file for editing:
5. Modify the values for the following properties to contain the connection settings of your database:
6. Make sure to restart all Backendless components after the changes are made.

External Redis

1. For scalability reasons, it is recommended to start multiple Redis processes where Backendless stores different types of data. The configuration file containing information for all connections is <installdir>/apps/backendless/htdocs/conf/redis.properties. The file includes  thirteen configuration sections, which means you could have up to tirteen Redis instances, each responsible for storing specific type of Backendless data. At the minimum, it is recommended to have at least two Redis instances: one for CodeRunner Debugger and the other for all other purposes (it is referenced as the "production" Redis in this documentation). This is how the default installation of Backendless is configured. Open redis.properties for editing.
2. Change all .host properties to the hostname of an external Redis server.
3. Change all .port properties to the port number of an external Redis server.
4. Notice that all config.redis.bl.config. properties point to a separate Redis instance. This is the Redis used by CodeRunner Debugger
5. Open the following file for editing:
6. Change system.redis.master.host to the hostname of the "production" Redis server.
7. If Redis is started with a password, set the password value in the system.redis.master.password configuration property. Otherwise, remove the line.
8. Open the following file for editing:
9. Change the "host", "port" and "password" properties in the "msgBroker" element to point to the "production" Redis instance.

External MongoDB

1. Open the following file for editing:
2. Change all .host, .port, .user and .password properties to contain connection information of an external MongoDB server.


Developer Accounts

Accounts of developers registered with your installation of Backendless Pro can be administered directly in the Backendless MariaDB database. It is recommended to use MySQL Workbench to establish a connection with the database, however, any tool supporting MariaDB connectivity and data modification will suffice.


Establish a connection with the database using the parameters described below. The values can be obtained from <installdir>/apps/backendless/htdocs/conf/connection.config


Once a connection is established, navigate to the main_backendless schema.


Disabling a developer account

When a developer account is disabled, the developer will not be able to login, however, all his/her applications will remain intact. To disable an account:

Open the Developer table and run the following SQL query to locate the developer account:

SELECT * FROM main_backendless.Developer where email='developer-email-address'

where developer-email-address is the email address of the developer whose account should be disabled.


When you make sure the account can be found, run the following query to disable the login:

UPDATE main_backendless.Developer SET developerStatusId = 2 where email='developer-email-address'


Assigning developer's apps to another developer

Moving apps from one developer account to another can be done using Backendless Console. Suppose there are two developers: Jack and Bob. To assign Jack's apps to Bob, the following process must be followed:


1. Bob must register and create a developer account.
2. Jack sends an invitation to Bob using the Invite a Team Member button in the Team interface in Backendless Console. The interface is available in the Manage > App Settings > Team section.
3. Bob receives an email with a link to join the app/project. When Bob clicks the link in the email, he is automatically added to the app's 'development team'.
4. Jack (being the 'owner' of the app) logs in to Backendless Console and navigates to the Manage > App Settings > Development Team section.
5. Jack changes the app permissions for Bob and removes himself from the development team.


If the steps described above are not possible, apps can be reassigned from one developer to another directly in the database. Using the example above where there are two developers: Jack and Bob. To assign Jack's apps to Bob:

1. Locate Jack's developer id by running the following SQL query with ack's email address:

SELECT id FROM main_backendless.Developer where email='developer-email-address'

2. Locate Bob's developer id by running the same query as above but with Bob's email address.
3. Run the following query to reassign Jack's apps to Bob:

UPDATE main_backendless.AppToDeveloper set developerId = 'bobs-developer-id' where developerId='jacks-developer-id'


Deleting a developer account

Open the Developer table and run the following SQL query to delete the developer account:

DELETE FROM main_backendless.Developer where email='developer-email-address'

where developer-email-address is the email address of the developer whose account should be deleted.


For the installations created with Native Installers, the installation directory is selected during the installation.

A Backendless Pro installation includes a graphical interface utility enabling runtime control of individual processes making up the product stack. To start the utility, double click the file named 'manager-linux' on Linux, 'manager-osx' on Mac OS or 'manager-windows.exe' on Windows from your file browser. The utility is located in the product's installation directory:



Process Control with Command Line

As an alternative to the graphical app manager, individual components of the Backendless stack can be started/stopped using CLI (command line interface).


Linux and Mac OS

To start/stop/restart Backendless components on Linux and Mac OS you can use the ctlscript.sh utility located in the product's installation directory, as shown below:


  ./ctlscript.sh help

  ./ctlscript.sh (start|stop|restart|status)

  ./ctlscript.sh (start|stop|restart|status) mysql

  ./ctlscript.sh (start|stop|restart|status) mongodb

  ./ctlscript.sh (start|stop|restart|status) apache

  ./ctlscript.sh (start|stop|restart|status) nginx

  ./ctlscript.sh (start|stop|restart|status) redis

  ./ctlscript.sh (start|stop|restart|status) taskman

  ./ctlscript.sh (start|stop|restart|status) play

  ./ctlscript.sh (start|stop|restart|status) debug_redis

  ./ctlscript.sh (start|stop|restart|status) coderunner


For example, to start all components run the ctlscript.sh script with the start argument.

./ctlscript.sh start


Individual components making up the Backendless Pro stack run as windows services. Product installation includes command line scripts to start/stop and to install/uninstall individual services. The scripts are located in the <installdir> directory. The scripts support the following scenarios:


Start all Backendless services:

<installdir>\servicerun.bat START


Stop all Backendless services:

<installdir>\servicerun.bat STOP


Uninstall all Backendless components as Windows services:

<installdir>\serviceinstall.bat REMOVE


Install all Backendless components as Windows services:

<installdir>\serviceinstall.bat INSTALL

Using Backendless SDK

All distributions of Backendless SDK are configured to communicate with the Backendless Cloud installation by default. When using an SDK with Backendless Pro it is important to modify the API endpoint URL to point the SDK to your installation. To configure the endpoint in your application code, use the following API:



com.backendless.Backendless.setUrl( "http://SERVER-IP-OR-DOMAIN-NAME:8080/api" );


backendless.hostURL = @"http://SERVER-IP-OR-DOMAIN-NAME:8080/api";


Backendless.serverURL = "http://SERVER-IP-OR-DOMAIN-NAME:8080/api";


BackendlessAPI.Backendless.URL = "http://SERVER-IP-OR-DOMAIN-NAME:8080/api";


Backendless::setUrl( "http://SERVER-IP-OR-DOMAIN-NAME:8080/api")

All other API calls with Standalone Backendless work exactly the same as with Backendless Cloud deployment.

Using CodeRunner SDK

The CodeRunner utility provided within the CodeRunner SDK can be used to develop custom business logic (server-side code) which subsequently is deployed to your Backendless Pro installation. The default settings of CodeRunner point to the Backendless Cloud servers and hence must be modified to work with your installation. To make the changes:


CodeRunner SDK for Java

1. Locate runner.properties in the /bin folder of the CodeRunner SDK and open it in a text editor.
2. Modify the following properties with the values as shown below:
system.server.url = http://SERVER-IP-OR-DOMAIN-NAME
system.redis.master.host = SERVER-IP-OR-DOMAIN-NAME
system.redis.master.port = 7738
where SERVER-IP-OR-DOMAIN-NAME is the IP address or the domain name of your Backendless Pro installation.

CodeRunner SDK for JavaScript

CodeRunner for JavaScript is not currently included into the distribution of Backendless Pro. It will be available in the near future. However, it is possible to use the CodeRunner for JS in the debug mode. See the instructions below to configure a local copy of the CodeRunner to work with your installation of Backendless Pro:

1. Locate coderunner.json in the root directory of the CodeRunner distribution and open it in a text editor.
2. Modify the following properties with the values show below:
  "backendless": {
    "apiServer": "https://SERVER-IP-OR-DOMAIN-NAME",
    "msgBroker": {
      "host": "SERVER-IP-OR-DOMAIN-NAME",
      "port": 7738,
      "password": "PASSWORD-VALUE-FOR-REDIS",
      "max_attempts": 5
where SERVER-IP-OR-DOMAIN-NAME is the IP address or the domain name of your Backendless Pro installation.

When Backendless Pro is installed in a public cloud environment such as Amazon Web Services, make sure to configure security policy to open port 7738 to allow connectivity for CodeRunner Debugger.

Functional Limits

Backendless Pro does not have any functional limits. All the limits found in the Cloud version of the product are removed or can be configured as described below.


Business Logic Timer Frequency

Server-code timers can run as frequently as every second.


Business Logic Timers Timeout

This is the runtime duration (in seconds) of a timer task before it is interrupted. The value can be modified in the <installdir>/apps/backendless/htdocs/conf/timers.properties file.


API Call timeout

This is the maximum duration (in seconds) for an API call to return a value to the client. The value can be modified in the <installdir>/apps/backendless/htdocs/conf/server.properties file. See the config.server.apiCallTimeout property.


Data Service Page Size

Backendless Pro provides a way to customize maximum page size for paged data retrieval. The default value is 100 objects. It can be modified in a configuration file located at: <installdir>/apps/backendless/htdocs/conf/pagesize.properties.


Make sure to restart all Backendless Pro processes after changing any of the configuration files.


A license file is required to unlock complete functionality of Backendless Pro. An unlicensed installation runs for 2 hours after it is launched and is limited to the single-threaded (single client) processing of API requests. To purchase a license or arrange product evaluation submit the "License Request" form on the website.


Once you have a valid license key file, it should be installed using Backendless Console:

1. Click the License link in the upper section of Backendless Console:
2. Use the Browse button to locate the license file (file must have the .l4j extension). Once the file is selected, click the Deploy License button.
3. After the license file is deployed, the License popup will show the licensing information. If the license has an expiration date, it will be displayed in the popup. Backendless Pro will stop responding to the API requests when the license expires. The Backendless nodes item displays how many Backendless Pro servers are allowed by the license key.


Updating Expired License Key

When a license key which has an expiration date expires, some Backendless processes (Play, CodeRunner, Task Manager) will stop and cannot be restarted. In this case, the license file must be updated manually:

1. Obtain a new license file by contacting Backendless sales.
2. Locate the following directories:
3. Replace license.l4j file in the directories shown above with the new license file. Make sure the license file is called license.l4j.

Deployment Scenarios

This chapter reviews various configurations of the service and describes advantages and disadvantages of each.


Single instance setup

Multi instance setup - without replication

Multi instance setup - with replication

Multi instance setup - with an external load balancer

Multi instance setup - with AWS services

Single instance setup

The most basic setup of Backendless Pro is an installation created by the installer. In that case all Backendless components run on the same machine (physical or virtual). The Single instance setup is the simplest form of Backendless. Since it is available right out of the installer, it is convenient to work with. It is recommended primarily for development purposes. Using Single Instance Setup in production is not recommended as manifests a single point of failure problem. Failure of any of the components would result in service not being available.


Multi Instance Setup - without replication

This configuration significantly increases stability and partially removes a single point of failure. The configuration can be achieved by following the instructions from the Clustering section. The configuration increases transactional throughput supported by the installation, however, a failure of the  Apache server, the database or the redis nodes would result in service unavailability.


Multi instance setup with replication

This configuration is similar to the one above except, as the title suggests, there is replication between the MariaDB, MongoDB and the Redis nodes. As a result of the replication, there is no single point of failure related to the databases and Redis. Any failure of these components does not impact the uptime of the service as the components rely on the failover connections (shown as a dotted green line). Although this setup presents the most stable configuration in comparison to the other two described above, it still lacks reliability at the web-tier (the Apache server). The Apache server on machine 1 performs the function of load balancer. Failure of the Apache server will lead to service unavailability. The diagrams below show the configuration of the system for machine1 and machine2:



Multi instance setup - with an external load balancer

This configuration is a progression of the previous one. It introduces an external load balancer, thus removing dependency on a specific machine for the function of routing API/console traffic. The load balancer shown in the diagram may be either a physical device or a virtual one (for example DNS-based load balancing). For the cloud-based deployments in Amazon Web Services or Microsoft Azure, load balancers offered by the respective providers naturally fit in this configuration:


Multi instance setup - with AWS services

Amazon offers various services which can be leveraged in a Backendless cluster configuration to gain additional reliability and instant scalability. This configuration uses Amazon ELB, RDS and ElastiCache:

The ELB component performs the function of LoadBalancer.
Amazon RDS is a relational storage service which replaces the MariaDB component.
Amazon ElastiCache - provides the Redis functionality.


The instructions below are for configuring a multi-instance cluster of Backendless Pro with Amazon ElastiCache, RDS, ELB and EFS.


Amazon Environment Setup

1. Launch an RDS instance. See Amazon's Quick Start guide for MariaDB/RDS for details.
2. Once the RDS instance is launched, connect to it using the credentials defined while setting up RDS. The instance endpoint cam be obtained from RDS console:
3. Create new Parameter group on the RDS dashboard per the instructions from the RDS User guide.
4. Configure the created parameter group
Set max_connections to 1000
Set log_bin_trust_function_creators to 1
5. Assign created group to the created RDS: go to Instances > Instance Actions > Modify; in the Database options section select the created group in DB Parameter Group.
6. Run the following scripts to setup the Backendless database:
7. Start two ElastiCache clusters. by following the instructions from the Amazon's Quick Start guide for ElastiCache. Make sure to select the Redis engine. The cluster names should be "prod" and "debug". The "debug" instance can be as small as possible.
8. Configure Elastic Load Balancer (ELB). Amazon Quick Start guide for ELB.
9. When configuring a health check for the EC2 instances where Backendless Pro will run, the path should be /api
10. Configure Elastic File System (EFS) per the instructions from the Amazon's Quick Start guide for EFS.
11. The file system target directory on the EC2 instances must be:
12. Make sure the AWS security group configuration applied to all components in your cluster is defined as shown below:


Backendless Server Installation


1. Choose an EC2 instance type with at least 8GB or RAM. Greater amount of RAM will improve overall performance of your Backendless installation.
2. Connect to the EC2 instance using SSH. To get the instructions on how to connect to the instance, select a running instance in the AWS Console and right-click Connect to get the instructions.
3. Download a suitable installer for the operating system running on the instance. For example for Linux run the following command:
wget "<link_to_installer>"
4. Make sure the installer  file is executable. For example for Linux run the following command:
chmod +x <installer_file.run>
5. Run the installer. When asked for the host name, paste the ELB DNS name from the AWS management console:


Backendless Configuration

Connect to the EC2 instance where Backendless Pro is installed and open <installdir>/apps/backendless/htdocs/conf/connection.config for editing. Modify the following properties to point to your RDS endpoint:






The cluster diagram above shows the centralized MongoDB database running on Machine 1. Make the changes below to point Machine 2 to the database running on Machine 1. The changes must be made in <installdir>/apps/backendless/htdocs/conf/mongo.properties.


Open <installdir>/apps/backendless/htdocs/conf/redis.properties: for editing. Modify the following properties to point to the "debug" ElastiCache node endpoint:





Configure all other properties in the file to point to the "prod" ElastiCache node endpoint:


CodeRunner Changes

Make the following changes in: <installdir>/apps/backendless/modules/java_coderunner/bin/runner.properties:

1. Change system.redis.master.host to the "prod" ElastiCache node endpoint.
2. Remove the system.redis.master.password line.


Make the following changes in <installdir>/apps/backendless/modules/js_coderunner/bin/coderunner.json:

1. Change host, port in the msgBroker element to point to the "prod" ElastiCache node endpoint.
2. Remove the password element.


database script

1. Open the following file for editing:
2. Remove all occurrences of "DEFINER=`root`@`localhost`" and "DEFINER = CURRENT_USER"


Amazon ELB can be configured with the elasticity rules to launch additional Backendless instances in response to greater load. Amazon RDS and ElastiCache make it easy to operate and scale persistent and in-memory stored application data.



A general guideline for Backendless Pro troubleshooting is to start with the log files. Product stores log files in the following directory:




The directory contains log files for the Play! server, Task Manager and CodeRunner.


If you run into an issue not documented in the table below, contact Backendless support. Please include the log files from the directory above.


Problem symptoms

Possible reason.

Suggested solution or workaround

Play server suddenly stops. This may occur during some specific operations such as data import/export or retrieval of large datasets.

Not enough memory allocated to the Play process.

Not enough memory is allocated to the Play process. Additional memory allocation can be configured in the launch script.


Linux and Mac OS

All launch scripts are located in the <installdir>/apps/backendless/scripts directory. The one for play is ctl_play.sh.


To expand the assigned heap size for instance to 8gb, add the following argument and restart the Play process:


- Xmx8g


The argument should be added right after "<INSTALLPATH>/java/bin/java" in ctl_play.sh.



locate the following file:




Scroll to the bottom of the file and add the following property. The example below will set Java heap size to 8gb, make sure you have that much memory, or alternatively use a smaller number:




Save the file. Use "App Manager" to stop/start the BackendlessPlayServer service. Or alternatively, open command prompt window and change the current directory to:




Run the following commands:

servicerun_play STOP

servicerun_play START

Play server does not start. Attempting to relaunch the process does not succeed, AppManager shows the process status asStarting..., however, after some time the process status changes back to Stopped.

Under some circumstances when Backendless is forcefully shutdown (for instance, as a result of power outage), there is intermediate "state" in the form of a file called RUNNING_PID. When starting the Play server it checks if the file already exists which is interpreted as the server is already running.

Delete RUNNING_PID from:



MongoDB server does not start. The symptom is similar to the one described above.

See above, however the file is mondodb.pid.

Delete mongodb.pid from: