Font size

Private Cloud configuration files

The Private Cloud installation package creates a profile for an administrator user and places the configuration files within their directory. The default location for these files (provided the administrator user has the default name alcadm) is as follows:


Within this directory, all Cloud data and configuration files are preserved for further usage.

The alc directory includes the following sub-directories:

  • anylogic-private-cloud — Contains the registry data, as well as the Docker images that are used to create Docker containers that run Private Cloud services.
  • cache — Contains data of all Cloud services. Includes the following directories that correspond to specific service components:
    • balancer
    • cassandra — stores persistent data
    • dynproxy
    • executor
    • executor-multi-run
    • experiment-results
    • fileserver — stores persistent data
    • frontend — stores persistent data
    • postgres — stores persistent data
    • rabbitmq — stores persistent data
    • rest
    • statistics
    In addition, each of these directories is attached to a corresponding Cloud Docker container as a Docker volume.
  • controller — Stores configuration files of the controller service and other Cloud components. For more information, see Controller configuration files and Service configuration files below.

Controller configuration files

The controller folder includes multiple configuration files in the JSON format. The example content snippets below include comments that identify the purpose of each JSON field.


This file lists all service components — applications — of Cloud, in the form of a JSON array.

Each service component is represented as a separate JSON object which has the following format:

  "deployOrder" : 55, // The order in which this application will be started by controller.
  "name" : "rest", // The name of the application.
  "image" : "", // A Docker image to use to create the application.
  "cmdArgs" : "", // Arguments to append to the Docker run command in the very end.
  "volume" : null, // A Docker volume to attach to the application container.
  "envVars" : [ ], // Environment variables to set using the -e run option of Docker. Example: "envVars" : [ "var1=xx", "var2=yy" ]
  "portMappings" : [ { // An array of ports which you want to forward into the container using the -p run option of Docker.
    "host" : 9101, // The port to open on the node (the machine that hosts the application).
    "container" : 9101, // The port inside the container.
    "protocol" : null // A protocol to use — may be tcp or udp, set to null to use both.
  } ],
  "stateEndpoint" : null, // If the application has a REST endpoint that can be used to identify its state, put it there. Example: "/state".
  "javaArgs" : [ ] // an array of the Java virtual machine arguments that you want to append to the Java command executed inside the container. Example: "javaArgs" : [ "-Xmx256M", "-Xms128M" ].
  "dockerArgs" : [ ] // An array of Docker arguments that you want to be passed within the container launch command. Example: "dockerArgs" : [ "--cidfile=/tmp/rest-cid", "--net=host" ].
Although controller is present within the application list, it is only for consistency — and proper handling of restart commands and the like. Any context-specific values specified within the controller object within applications.json are ignored.


This file contains an array of JSON objects which represent nodes — host machines that run Cloud service components. Each such object also includes a list of services that run on that specific machine.

The format of the node object is as follows:

[ {
  "host" : "", // The DNS name or IP address of the host.
  "sshAccess" : {
    "method" : "PRIVATE_KEY", // The method you want to use to connect to the host’s SSH interface. Possible options: PRIVATE_KEY, PASSWORD. Default value: PRIVATE_KEY — it is highly recommended to use this option.
    "user" : "alcadm", // The user name you want to use while connecting to the host.
    "key" : "id_rsa" // If method is set to "PRIVATE_KEY", this value specifies the name of the key file you want to use to connect to the host. You can find these files within the keys directory. If method is set to "PASSWORD", this value specifies a plain text password you want to use to connect to the host.
  "volumeRoot" : "/home/alcadm/alc/cache", // The root directory where the container volumes will be stored.
// An array of the names of applications that will run on this node:
  "labels" : [ "controller", "rest", "balancer", "fileserver", "cassandra", "experiment-results", "executor", "executor-multi-run", "dynproxy", "rabbitmq", "postgres", "frontend", "statistics" ],
  "stoppable" : false, // This is ignored in Private Cloud.
  "manageable" : true // Whether the controller should monitor this node and start services there or not. It is not recommended to modify this value in Private Cloud instances.
} ]


This file stores passwords for PostgreSQL and MinIO file servers that are used across updates.

If during an update other configuration files are recreated, the passwords from this file will be used.

  "postgres": "%random string%",
  "minioAccess": "%random string%",
  "minioSecret": "%random string%"


The main configuration file of the controller component.

The file has the following format:

  "registry" : "", // The Docker Registry server. The controller service pulls Cloud Docker images from there. By default, in /etc/hosts points at
  "environment" : "private", // Do not modify this value in Private cloud.
  "controllerAddress" : { // The address of the node which runs the controller and the controller port. These values are passed to other Cloud services as environment variables.
    "host" : "",
    "port" : 9000
  "logServiceAddress" : { // The address of the RabbitMQ log server.
    "host" : "-", // The - character, when set as a value of host, indicates the absence of a dedicated log server. In this case, logs are received by executing the Docker logs command.
    "port" : 0   },   "nodeCheck" : { // The interval at which the periodic service status checks occur.
    "period" : 10, // At such an interval, the controller service will connect to the nodes through the SSH interface and check whether any service needs to be started.
    "unit" : "SECONDS"
  "nodesMonitorCheck" : { // The interval for nodes’ periodic check.
    "period" : 5, // Not used in Private Cloud.
    "unit" : "SECONDS"

Controller sub-directories

The controller folder includes the following sub-directories:

  • keys — Contains private SSH keys for the nodes. To establish an SSH connection, Cloud uses the JSch library.
  • email-templates — Contains the templates of service email notifications that can be sent from Cloud.
  • preload — Contains service files that are copied to the running application’s cache directory. Each sub-directory in preload must be named after the corresponding application.
    As of now, this sub-directory contains only the frontend directory. In there, the NGINX configuration of the Cloud web interface resides.

Service configuration files

These configuration files are located in the controller data directory. By default, their location is as follows:


Each of these files may be used by multiple service components.

To apply any changes made in these files, restart the controller component by executing the following command:
sudo docker restart controller rest


This file is used by the balancer service component. It holds RabbitMQ queues consisting of model run tasks — these tasks are submitted to executor service components.

If a task cannot be picked by an executor service immediately, it is appended to a queue. This may happen, for instance, when all nodes are busy running other tasks.

Depending on the rejection status, the task may eventually turn up in the “soft” or “hard” rejection queue.

The configuration file specifies how many tasks can be pulled from each queue. It also defines the “sleep” period between such pulls.

  "softRejected" : {
  "pullTasksCount" : 10,
  "pullPeriod" : {
    "period" : 5,
    "unit" : "SECONDS"
  "hardRejected" : {
  "pullTasksCount" : 2,
  "pullPeriod" : {
    "period" : 15,
    "unit" : "SECONDS"


Cloud has policies that define resource limits for subscription and free users in public Cloud.

For Private Cloud instances, there is no point in modifying the default configuration of these policies, since there is no difference between subscription and free users. Given that, no additional limits are actually in effect.

  "experimentRunLimits": "experimentRunLimits:privateCloud",
  "sandboxing": "sandboxing:soft",
  "accountType": "accountType:free",
  "experimentRunMaxMemoryMB": "experimentRunMaxMemoryMB:privateCloud"


This file contains the email server configuration. For Cloud to be able to send email notifications, you have to supply the data of an SMPT relay server in there.

  "smtpServer" : "", // The IP address or FQDN of an SMTP server.
  "supportMailbox" : "", // The email address that will receive the messages with support requests.
  "internalNotificationsMailbox" : "" // The email address of a server administrator.


This file contains configuration options for the executor service component which runs the models.

Most of these options should not be modified.

    "appsRootDir" : "/opt/anylogic/", // The directory inside the executor container that stores the JAR file of the executor component. 
    // Should not be edited in any way.
    "s3CacheDir" : "/var/cache/executor/", // The directory inside the executor container where executor stores the JAR file of the model and its resources
    "logsDir" : "/var/log/executor/", // The directory inside the executor container where executor stores the model execution logs
    "sessionsDir" : "/var/run/executor/", // The directory inside the executor container where executor creates temporary environments for model execution
    "sessionTimeout" : "300", // The timeout (in seconds) for the animation session activity. The executor component stops the animation sessions that are inactive for the specified period period
    "securityManagerEnabled" : false, // Allows to specify whether Private Cloud should use Java Security Manager.
    // If true, the models are launched in a "sandbox", using Java Security Manager. This may have a huge impact on the model execution performance, reducing the speed in 2-3 times
    "totalOutputFilesSizeLimitMB" : 256 // The maximum allowed size (in MB) for files that can be used as model output. Due to restrictions in the internal Cloud policies, cannot be increased, but you can reduce it as you see fit


This file contains the S3 backend configuration. Private Cloud uses the MinIO server (a file server Docker container) for S3.

There is usually no need to modify this configuration. The access key and secret key are generated randomly during the installation of Cloud.

Any modification to these case will prevent Cloud from connecting to MinIO and break the expected workflow of Cloud.

  "provider" : "MINIO",
  "s3Configuration" : {
    "bucket" : "",
    "root" : "",
    "amazonConfiguration" : {
      "region" : "",
      "accessKey" : "",
      "secretKey" : ""
  "minioConfiguration" : {
    "bucket" : "anylogic-cloud",
    "accessKey" : "NS7GKSEk",
    "secretKey" : "Y8wdZ7hm0SiEgTuH"


This file contains the UUID and optional name for the highlighted user: models this user uploads to Cloud will appear in the Selected Models section of the title screen of Cloud.

If this user does not have a username specified in their profile page, their first and last name will be displayed instead.


This file contains the external public address of the Cloud installation. By using this URL, your users will be able to open the Cloud web interface. The same URL will be used in AnyLogic desktop installations to export models to Cloud.

A proper Cloud instance URL must start with the protocol specified explicitly — that is, http:// or https://.

It is not recommended to switch between protocols without reinstalling Private Cloud. There are cases when it may be necessary, for example, when using the HTTPS proxy set up on an Elastic Load Balancer — but in general, you should avoid modifying the protocol and address of your instance in the file.

You may choose to specify a non-default port: in that case, specify it at the end of the address. Provided the port is not specified, the default port is used — 80 for HTTP, 443 for HTTPS.

  "gatewayHost" : ""


This file contains an option that defines whether the registration via the web interface is available in the Private Cloud instance. Set the option to false to disable the registration form on the login screen and corresponding API.

If the registration is disabled, the only way to add new users to the Cloud instance is by using the functionality of the corresponding tab on the administrator panel.

Additionally, the enableGuestAccess option defines if Private Cloud is available to guests. If this option is set to false, the Guest tab on the login screen and guests’ access to public models become unavailable. To use Cloud, your users will need to sign up first.

  "enabled" : true,
  "enableGuestAccess" : true

statistics-db.json and rest.json

These two files contain references to Cloud SQL databases: names and authentication credentials.

By default, Cloud has two databases: anylogic_cloud holds the metadata (that is, users, models, options, comments, and so on), while anylogic_cloud_statistics serves as storage for model run results, logins, and information on nodes’ operation.

Do not modify rest.json in any way. Doing so will make your Private Cloud instance unusable.

You may choose to modify data in statistics-db.json, provided you are well aware of the possible results of your actions.

  "dbname" : "anylogic_cloud_statistics",
  "username" : "postgres",
  "password" : "JuP7spIzL3im7VGN"


This file contains the configuration of the executor-multi-run service component.

  "maxTasks": 1024, // The maximum amount of tasks a single multi-run-executor will process simultaneously. Tasks that don’t get into this limit will be retried.
  "maxSingleRunsInMultiRun": 65534 // The maximum amount of single runs in one multi-run experiment.
How can we improve this article?