The Application represent the software you can host in your Clouder. In this chapter, we’ll see how we can configure them.

Application Types

This menu contain the list of application type defined in your Clouder. They are mainly just a tag so the python code can know which code shall be executed, depending of the type of the application.


Since it’s so deeply connected with the python code, you shall never create an application type through the graphical interface, it shall always be defined in a template module.


It contains :

  • The name of the type, can only contains lowercase, digit or hyphen.
  • The system user which will run the applications.
  • Finally, if the application needs several databases (like seafile), you can indicate in the multiple databases fields the name of the databases which need to be created.

In the application type you can also define the options. Options allow to manage configuration settings specifics to an application type, so you can manage some values needed for your python code without having to add new fields in the Clouder interface.

An option can be assigned to applications, containers, services or bases. In the application type you’ll define the possible options for each objects, and the values will be defined in the objects.

Each option has :

  • The name of the option, can only contains lowercase, digit or underscore.
  • The type of object where the value of the option will be defined.
  • If the option shall be suggested when you create a new record in the designed object.
  • If this option is required, if set to True you’ll not be able to create a new record if the option is not set.
  • Finally, the default value for this option if needed.


The application represent the software which will be hosted in your Clouder. You can have several applications for each application types.


For example, for the application type odoo, you can have three applications:

  • An Odoo application, which will just install a regular Odoo with only the base module.
  • A Clouder application, to host Clouder for other peoples (Yeah!). It will add the clouder modules in the application archive and auto install the clouder module thanks to the install_modules option. A Clouder application is nothing more than a verticalisation.
Since the modules can be installed automatically when the base is deployed, this mean you can easily create your own verticalisation with modules your developped or you like, and add a form on your website so your visitors will be able to automatically get their own instances of your verticalisation.
We took the example of Odoo, but it works with any software which have a module system, like Drupal, Wordpress etc… If you know a lot of very good modules and want to share this knowledge you can easily use Clouder to build a package which your visitors can install in just a few click.

Let’s get back to the application form. For each application you can define :

  • The application name, no restrictions here.
  • The templates it inherit (define options and links). Templates are very useful to deduplicate some very redundant code in modules.
  • The application type of the application.
  • The application code, can only contains lowercase, digit or hyphen. Note that since this code will be used is many location in your infrastructure, you can’t change his value once defined.
  • The current version of the application. This is used for the version name which will use the format ${current_version}.${current_datetime}.
  • The tags of the application, often used to trigger some action in the code.
  • If the application can deploy a base, hence if the application is a web application. For example an Odoo application can deploy a base, but not a postfix application.
  • The default image/version which shall be used for this application when we deploy a container.
  • The next node/service to use for this application, if you create a new base without providing a service it will automatically deploy a new service in this node.
  • The default admin name and email, theses options can be overridden in the base.
  • Check the public checkbox if you want all users of the Clouder to be able to use this application. Otherwise, a user can only access an application if he is the manager of this application (or an administrator).
  • The sequence is used if this application has a parent application, to know the order the child shall be deployed. Obviously very important, you don’t want to deploy Exec container before Data container.
  • The required field, again used if this application is a child the application will be auto-deployed when parent is deployed.
  • The update strategy, if this application shall be updated each day with the new image from Docker Hub (Exec), if it shall be manually updated with a button when needed (Files) or never (Data). Updating Exec each day is important for security reasons, this is the exposed container.
  • Update base, if an update if this service shall update bases linked to it. For example, when we update Odoo files service.
  • Dummy, if this service shall not deploy any container, even if it does not have children. This is used for LibCloud services, which will connect to cloud API and not deploy container.
  • Provider, if we want to display the provider field in service form, again for LibCloud services.

Next you have the options configuration, where you can define the values for the options specifics to this application.

Following, you have the links configuration. Theses are an extremely important concept, you can link an application to the others in order to build a coherent infrastructure. For example, an Odoo container by himself can’t work, you need at least to link it to a Postgres container so it can have their databases. Same, you can link the Odoo container to a Postfix container for sending and receiving emails, a Proxy container for redirecting the defaults ports to Odoo and adding the https, a Shinken container to make sure it’s always up and get stats, a Bind container to assign a domain name to the Odoo base, a Piwik to get analytic stats etc… When a link is deployed, some specific python code will be called and will make sure the other container know the existence of this container and adapt his configuration.

Very similar to the options interface, links are configured in the application form and are defined in the containers/services/bases. So for each link you can define :

  • The application to link.
  • If this link is required, if set to True you’ll not be able to create a new record if the link is not set.
  • If the link shall be suggested when you create a new record in the designed object.
  • If a direct docker link shall be made between the two containers. This improve security for the communications between the containers but require the containers to be in the same server.
  • The type of object where this link shall be available (service/base)
  • The next container which shall be used for this link. If filled, the link will be autocompleted in the container/service/base.

Then after the links, you can specify if this application have children, in a many2many field. When deploying this application, all children will be created as sub-services and deploy in the order.

Finally, on the backup tab you can manage the save options for this application. You can specify :

  • The backup services for containers and bases.
  • The time between each automatic save. Since some backup methods use global deduplication, you can make frequent saves without having to worry too much about disk space in the backup container.
  • The time between each save repository change the time before a repository is deleted. Check the Backup chapter for more informations about repositories and their utilities.
  • The time before a backup expiration.

All theses settings are inherited but can be changed in containers and bases forms.