Login/Register
Support

Installatron Server Administration Portal


Administration

Documentation for installing, using, updating, transferring, and uninstalling Installatron Server.

◎ Install
◎ Upgrade
◎ Transfer
◎ Uninstall (Linux)
◎ Uninstall (Windows)

Administration

Advanced Installatron Server configuration topics like clustering.

◎ Clustering: Scaling

Glossary

  • Clustering

    1. verb: When using Installatron Server, clustering is the addition of nodes to scale the service.

    (see: Clustering: High Availability & Scaling)

  • Installatron Plugin

    1. noun: The action of using Installatron to install an application, to create a new website.

    (see: Installatron Plugin)

  • Installatron Server

    1. noun: The standalone version of Installatron that administrators can hook into their own webhosting systems. (note: previously known as Installatron Servers)

    (see: Installatron Server)

  • Key

    1. noun: Installatron Server uses "a key" to track ownership. (Note that Installatron Plugin does not use a key, it instead uses a license.)

    (see: Installatron Server key)

  • License

    1. noun: Installatron Plugin uses "licenses" to track ownership. (Note that Installatron Server does not use a license, it instead uses a key.)

    2. noun: Some of the applications installed by Installatron also have an optional "pro" version which uses a license.

    (see: Installatron Plugin license)

Installatron Server Setup and Usage Guide

(revised 2025-03-26)

1. Introduction

Installatron Server is an API and optional UI that enables scalable and flexible application management to be integrated seamlessly into existing web hosting infrastructure.

Please reference the What is Installatron Server? page for more information about what Installatron Server is.

As outlined, there are two hosting options for Installatron Server:

  • Self-hosted (On Premise)
  • Cloud-hosted (On Installatron.com)

And three integration interfaces for Installatron Server:

  • HTTP API
  • Command-line API
  • Installatron Server UI

These interfaces are not mutually exclusive: you can use safely use multiple interfaces on the same Installatron Server instance. And the interfaces do not differ between self-hosted and cloud-hosted.

Installatron Server is mostly managed through API calls. To use Installatron Server, you will need to be comfortable using API-driven systems.

This document will explain how to use and interface with each hosting option, and offer suggestions for which methods work best in which situations.

2. Cloud-Hosted vs. Self-Hosted

    2.1. Cloud-hosted (On Installatron.com)

    The cloud-hosted instance of Installatron Server for your company is provisioned on Installatron.com's servers and managed by our team.

    This option is recommended for a low-maintenance, hassle-free solution:

    • No need to worry about infrastructure, software updates, or security patches.
    • Cloud-hosted instances automatically scale as usage increases.
    • Applications are managed using a standard FTP(S), SFTP, or SSH layer which connects to your web hosting platform.

    Follow these steps to use Installatron Server as a cloud service:

      2.1.1. Prerequisites

      Your web hosting platform will need to allow connections from Installatron.com. This may require firewall rule and rate limiting adjustments.

      There are no additional prerequisites because Installatron Server is hosted on Installatron.com.

      2.1.2. Get Started

      If you haven't done so already, you'll need to create an Installatron.com account and then log in.

      Afterwards, contact us to receive access and begin the integration process.

    2.2. Self-Hosted

    The self-hosted Installatron Server is installed on one or more servers on your network and managed by your team.

    This option is recommended to maximize data security and performance optimization:

    • Customer data never leaves your infrastructure, reducing third-party risks.
    • Multiple Installatron Server nodes can also be clustered for High Availability and Scalability.
    • Using local infrastructure ensures faster processing and lower latency.

    Follow these steps to deploy Installatron Server on your network:

      2.2.1. Prerequisites

      Installatron Server's architecture minimizes requirements while maximizing compatibility.

      At least one server with a permanent internet connection is required to run Installatron Server. Management of this server is your responsibility, and we recommend the following best practices:

      For small-to-medium production deployments we recommend starting with these hardware specifications:

      • 4 GB or more RAM
      • 100GB or more disk space
      • 4 or more CPU cores
      • 64-bit architecture

      For larger deployments, contact us for recommendations based on anticipated usage.

      Installatron Server supports the following Linux distributions:

      • Debian 12
      • Debian 11
      • Red Hat Enterprise Linux 9
      • Red Hat Enterprise Linux 8
      • CentOS Stream 9
      • CentOS Stream 8
      • AlmaLinux 9
      • AlmaLinux 8
      • Rocky Linux 9
      • Rocky Linux 8
      • Amazon Linux 2023
      • Amazon Linux 2

      We always recommend selecting a "minimal" variation of the distribution. Installatron Server will provision all necessary system services for you.

      When partitioning your disk, we recommend a straightforward partition structure of:

      • swap — The same as the amount of RAM on the server, but not more than 16 GB.
      • / — Remaining balance of available disk space.

      Finally, Installatron Server uses a MySQL database to store data. There are two options available:

      • By default, Installatron Server will provision and manage MySQL on the local server.
      • A second option to offload the database to a dedicated database server (Recommended for large deployments).

      This concludes the Self-Hosted best practices and prerequisites. Contact us with any questions.

      2.2.2. Generate a License Key

      If you haven't done so already, you'll need to create an Installatron.com account and then log in.

      You can now generate an Installatron Server License Key through your Installatron.com account portal.

      The generated License Key can be used on any number of Installatron Server instances.

      2.2.3. Download and Install

      Start by provisioning the server following the best practices outlined in the Prerequisites section above.

      Execute these commands from the SSH root command prompt (replace YOUR_LICENSE_KEY with the Installatron Server License Key generated in step 2.2.2):

      curl -O https://data.installatron.com/installatron-server.sh
chmod +x installatron-server.sh
yum -y remove httpd
./installatron-server.sh -f --key YOUR_LICENSE_KEY
      curl -O https://data.installatron.com/installatron-server.sh
chmod +x installatron-server.sh
yum -y remove httpd
./installatron-server.sh -f --key YOUR_LICENSE_KEY
      apt-get update
apt-get -y dist-upgrade
apt-get -y install curl net-tools
curl -O https://data.installatron.com/installatron-server.sh
chmod +x installatron-server.sh
./installatron-server.sh -f --key YOUR_LICENSE_KEY

      Note: If the MySQL database has been offloaded to a dedicated database server, or to add an additional Installatron Server node to a cluster, add these arguments to the install command:

      --db-host=sql.yourhost.com --db-user=youruser --db-pass=yourpass --db-name=itron

      That will take a couple minutes to install the system services and dependencies for Installatron Server. Contact us if you observe any issues during the process.

      Core files and programs are installed here:

      /usr/local/installatron/

      And Installatron's data files are installed here:

      /var/installatron/

3. Interfacing with Installatron Server

Installatron Server can be accessed via UI or through API calls: the APIs can be called from both CLI and over HTTP.

    3.1. Interfaces

    There are two ways to interface with Installatron Server, and it's worth noting that these interfaces are not mutually exclusive: they can both be used on the same server at any time.

      3.1.1. Accessing Installatron Server through UI

      See the /users/{id}/login for examples of using the Installatron Server UI.

    3.17.1 Accessing the UI as a website owner TODO: move this

    A session must be created before a user can be redirected to the Installatron Server UI. This is accomplished by issuing a "guixfer" request.

      Examples

      This example written in PHP initializes an Installatron Sever session and then redirects to the Installatron Server UI:

      
<?php
      $query       = array(
                /* these values define the request header: */
          // Note: "key" is the "key=" from /usr/local/installatron/etc/settings.ini
                "key" => "8327b11a311aad5a8092d26d209c9e13",
                "websites" => array(
              array(
                        "id" => "website123",
                        "label" => "website.com",
                        "path" => "ftp://".urlencode("website123")."@12.24.35.11",
                        "vhosts" => array(
                            "http://website.com" => "httpdocs",//@note it's assumed "path" is prefixed.
                            "http://www.website.com" => "httpdocs",
                  ),
                        "email" => "user@mail.com"
                    ),
              array(
                        "id" => "website124",
                        "label" => "company.com",
                        "path" => "ftp://".urlencode("website124")."@12.24.36.22",
                        "vhosts" => array(
                            "http://company.com" => "httpdocs",
                            "http://www.company.com" => "httpdocs",
                            "https://company.com" => "httpsdocs",
                            "https://www.company.com" => "httpsdocs",
                  ),
                        "email" => "user@mail.com",
                        // Because we are transferring the user into a UI, we need some mechanism to
                  // handle databases. See section 3.17.3 for more information.
                        "db_mode" => "manual",
                        "databases" => array(
                      array(
                                "type" => "mysql",
                                "host" => "localhost",
                                "name" => "db134",
                                "user" => "db134",
                                "pass" => "0sdhfldsafh"//Note: Providing a password is optional.
                            ),
                      array(
                                "type" => "mysql",
                                "host" => "localhost",
                                "name" => "db135",
                                "user" => "db135"
                            )
                  )
              )
          ),
                /* these values define the request body: */
                "cmd" => "guixfer",
                "language" => "en"
      );

      $ch = curl_init("http://installatron.yourhost.com/index.php");
      curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($query));
      curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);

      $reply = curl_exec($ch);

      if (       $reply === false )
      {
          echo       "An error occurred: ".curl_error($ch);
          return;
      }
      else if (       strpos($reply,"Error:") === 0 )
      {
          echo       "An error occurred: ".$reply;
          return;
      }

      $reply = json_decode($reply,true);

      if (       $reply["result"] === false )
      {
          echo       "An error occurred: ".$reply["message"];
          return;
      }

      header("Location: http://installatron.yourhost.com/index.php?s=".$reply["session_id"]);
    3.17.2 Accessing the UI as an administrative user or a reseller TODO: move this

    TODO: check that this has been moved to /apis/is/guixfer

    Using a similar guixfer request, sessions for administrator and reseller users can also be created. To create a UI session for an administrator, define the user member to match the "admin=" value in /usr/local/installatron/etc/settings.ini as shown below (the value is usually "admin"). To create a UI session for a reseller (or sub-reseller), define the user member to the name of the reseller.

    Note: Administrators and resellers can access the Installatron Server directly from the login screen if an account is pre-configured. By default the main administrator account is pre-configured. To pre-configure additional accounts reference 3.17.3. Create/edit user data within the Installatron Server database.

      List of arguments

      NAMEVALUE
      cmdguixfer
      key
      required
      part of the Request Header that must be included with all API requests
      typereseller
      userAn alphanumeric value that will represent the reseller. This argument will be used to index data and cannot change.
      reseller
      optional, default is the main administrator
      Assign ownership to a reseller instead of the main administrator.

      Example:

      
<?php
      $query       = array(
                /* these values define the request header: */
                "key" => "8327b11a311aad5a8092d26d209c9e13",
                "user" => "reseller123",
                /* these values define the request body: */
                "type" => "reseller",
                "cmd" => "guixfer",
      );

4. Maintaining Installatron Server

This additional information can help you understand your Installatron Server.

    4.1. How app updates work

    The settings at Installatron Admin > Settings control how frequently Installatron Server checks for new app updates by configuring the crontab process at "/etc/cron.d/installatron". When this crontab process executes, Installatron Server checks every installation to determine whether an update is available, and if automatic update is enabled then Installatron Server will automatically queue the update task, otherwise an email notification will be sent to inform the user to let them know that an update is available.

    Installatron Server utilizes a task queue to prevent the system from overloading from too many simultaneous tasks. No more than the number of tasks configured at Installatron Admin > Settings can execute concurrently.

    As of Installatron Server 4.1.15, a new setting at Installatron Admin > Features > Force Update After enables server administrators to configure Installatron Server to forcibly update installed apps after a set number of days have elapsed since the update became available. This feature can be useful to enforce an application update policy.

    4.2. Settings.ini values

    Installatron Server's "/usr/local/installatron/etc/settings.ini" configuration file is provisioned automatically during installation and generally doesn't require manual editing. But here are some typical lines found in the settings.ini file:

    NAMEVALUE
    key
    required
    The product key.
    noperl
    optional, default is "no"
    Installatron Server uses Perl .cgi files on the destination web server to speed up tasks. If Perl is not supported, this setting should be set to "yes" to avoid every task having to test Perl.
    update
    required, default is "release"
    The update channel. Valid values include "edge", "release", "stable", or "never" to switch off automatic updates.
    debug
    optional, default is "no"
    Set to "yes" to enable the debug log at /var/installatron/logs/debug_log which contains very verbose output which can be useful tracking down a multitude of issues.
    db_type
    required, default is "mysql"
    The type of database server. This setting is configured automatically during installation to use MySQL or MariaDB.
    db_host
    required for mysql, default is configured automatically
    The database server.
    db_name
    required for mysql, default is configured automatically
    The database.
    db_user
    required for mysql, default is configured automatically
    The database username.
    db_pass
    required for mysql, default is configured automatically
    The database password.
    num_cpu
    optional, default is the number of CPU threads multiplied by two
    The number of tasks allowed to execute concurrently systemwide.
    num_cpu_perserver
    optional, default is 5
    The number of tasks allowed to execute concurrently per web server.
    db_schema_update
    optional, default is yes
    Whether database schema updates should be automatically managed by Installatron (recommended: yes).

    4.3. Useful command-line tools

    Here are some useful CLI commands:

      Forcibly update/repair the entire system:

      /usr/local/installatron/repair -f --quick

      Create a single-use access token for the administrative UI:

      /usr/local/installatron/installatron --createsession

      Reset administrative login:

      /usr/local/installatron/installatron --repair --reset-admin

      Forcibly check for customer app updates for user named barry:

      /usr/local/installatron/installatron --taskscheduler --full --user barry

How to upgrade Installatron Server

Installatron automatically adds a Crontab or Windows Task Scheduler process to upgrade/update once per day. This automatic process can be disabled and re-enabled through Installatron's administration page.

To force an upgrade/update you can either:

1. Select the appropriate tab from these options and follow the instructions therein:

Run these commands as root (DON'T RUN THESE COMMANDS IF YOU ARE USING INSTALLATRON SERVER!):
		
		curl -O https://data.installatron.com/installatron-plugin.sh
		chmod +x installatron-plugin.sh
		./installatron-plugin.sh -f --quick

Tip: To run update in interactive mode, remove -f from the last command.

To perform an update on Installatron Plugin Windows, follow
		the same setups used to install Installatron Plugin.
		See: https://installatron.com/docs/plugin/install/installatron-plugin-plesk-windows
Run these commands as root (DON'T RUN THESE COMMANDS IF YOU ARE USING INSTALLATRON PLUGIN!):
		
		curl -O https://data.installatron.com/installatron-server.sh
		chmod +x installatron-server.sh
		./installatron-server.sh -f --quick

Tip: To run update in interactive mode, remove -f from the last command.

To perform an update on Installatron Server Windows, re-run the installatron-server.exe wizard.

Or, alternatively:

1. Open the "Administration" tab.


2. Click "Installatron" in the Administration section of the sidebar.


3. Click
run Installatron Update/Repair
.

How to transfer Installatron Server to another server

Installatron Server was previously named Installatron Server -- they are the same product

To transfer Installatron Server to another server and retain all existing installed applications, backups, and administrative settings:

  1. Create a fresh install of Installatron Server on the new server by following the install steps here.
  2. Next, edit this file (on the new server) and take note of the mysql_user= and mysql_pass= values; you're going to need them in a moment.
    3. /usr/local/installatron/etc/settings.ini
  3. Now copy these directories from the old server to the same locations on the new server:
    4. /var/installatron/data
/usr/local/installatron/etc
  4. Now edit /usr/local/installatron/etc/settings.ini again and replace the values of mysql_user= and mysql_pass= with the values that you saved from the file before it was overwritten. This will point Installatron back to the new database.
  5. If the old instance of Installatron Server uses a local MySQL database then transfer it to the the new server, overwriting the initial database created for the new install (ie. drop all the tables from the database and then import the .sql file into the now-empty database). Typically, the Installatron database is named "itron".
  6. ..or, if the old instance of Installatron Server uses a remote MySQL database, and you wish to continue using that remote database for the new Installatron Server instance, then when you install the new IS instance you can add the optional --db-host=, --db-user=, --db-pass=, and --db-name= parameters as described in the install steps.

Uninstall: Installatron Server Linux/FreeBSD/UNIX

To uninstall Installatron Server from a Linux/FreeBSD/UNIX server run the following from CLI as root:

Remove RPM package (if applicable):

rpm -e installatron-server

Remove Debian package (if applicable):

dpkg -r installatron-server

Delete the core:

rm -fr /usr/local/installatron
rm -f /etc/cron.d/installatron

Delete user install data (be careful!):

rm -fr /var/installatron

Uninstall: Installatron Server Windows

To uninstall Installatron Server from a Windows server run the following from CLI as root:

Delete the core:

rd \"%itron_dir%\\etc\" /S /Q
rd \"%itron_dir%\\lib\" /S /Q
\"%itron_dir%\\uninstall.exe\"

Delete user install data (be careful!):

rd \"%itron_dir%\\Data\" /S /Q

Clustering: High Availability and Scalability

(revised 2025-03-05)

1. Introduction

Installatron Server enables high availability and scalability by allowing multiple Installatron Server nodes to be clustered together. By leveraging a cluster of Installatron Server nodes, businesses can ensure that their Installatron Server deployment remains reliable, responsive, and ready to scale as required:

    1.1. High Availability

    High Availability (HA) refers to a Installatron Server's capability to remain operational and accessible even in the face of hardware failures, network issues, or other disruptions by distributing the API and UI requests across a cluster of nodes. In a high-availability configuration, redundancy and failover mechanisms help to ensure that services remain online with minimal downtime.

    • Redundancy
      In the event of a node failure, other nodes seamlessly take over processing requests, maintaining uninterrupted service.
    • Efficient Resource Utilization
      Workloads are balanced across available nodes, optimizing system performance.

    1.2. Scalability

    Scalability refers to Installatron Server's capability to handle an increase in API and UI requests by distributing the requests across a cluster of nodes. As demand increases, additional nodes can be added to the cluster to balance the load efficiently. This ensures that no single node is overwhelmed, maintaining optimal performance and responsiveness.

    • Load Balancing
      Requests are distributed across multiple nodes, preventing bottlenecks and helping to ensure no single node is overloaded.
    • Seamless Expansion
      Additional nodes can be integrated as needed, with the cluster automatically adjusting to balance new workloads efficiently.

2. Implementing

Start by configuring a single Installatron Server node following the typical installation instructions. While not required, you may choose to offload the MySQL/MariaDB database to a dedicated database server by including the necessary installation parameters.

Next, add your first additional Installatron Server node following the Additional Node installation instructions which instruct Installatron Server on the additional node to share the same database as the first Installatron Server node.

The first and second Installatron Server nodes are now clustered. They now share the same database and workload, helping to ensure the Installatron Server cluster as a whole remains dependable, efficient, and scalable to accommodate increasing demand.

Additional nodes can be added as demand requires by repeating the Additional Node step.

To remove a node, simply power off the node and the cluster will adapt to the removed node by consolidating requests to the remaining node(s).

    2.1. Advanced Load Balancing Options

    By default, requests are assigned to available nodes in a Round Robin manner, distributing traffic sequentially to help maintain an even load. If a node becomes unavailable, the remaining nodes automatically handle the requests to ensure continuity.

    A dedicated load balancer, though optional, serves as an intermediary that optimizes request distribution more efficiently. Load balancers can be configured in various ways to meet specific infrastructure needs and performance goals.

    Common load balancing configurations include:

    • Round Robin
      Requests are distributed sequentially across all available nodes, ensuring even distribution of traffic.
    • Least Connections
      Directs traffic to the node with the fewest active connections, optimizing resource utilization during peak loads.
    • Weighted Load Balancing
      Assigns different weights to nodes based on their processing power or capacity, ensuring that more powerful nodes handle a larger share of the requests.

Contact Installatron Support if you have any questions.

index
© 2004 - 2025 Installatron LLC. All rights reserved. Privacy Policy.