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:

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" ].

Note: 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:

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.

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


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 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://. Currently, it is impossible to switch between protocols without reinstalling the Cloud instance, so modifying this value within this file is not recommended.

You may choose to specify a non-default port: in that case, specify it in 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.

  "enabled" : 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.

Related topics

AnyLogic Private Cloud

AnyLogic Cloud

AnyLogic Cloud options