Documentation Index

Fetch the complete documentation index at: https://docs.insys-icom.com/llms.txt

Use this file to discover all available pages before exploring further.

Migration to Docker (iRM Version 2025.09.0b)

Prev Next

Prerequisites before Migration

Migrate icom Router management binary installation to Docker

Preface

The icom Router Management (iRM) Server installation by application binary will not be
supported anymore. The installation and operation of iRM via docker compose will now be
preferred. This guide addresses all users that currently have a running binary installation, and
want to switch to the docker compose installation. All following steps and the migration as a
whole should be executed on the machine that currently hosts the iRM Server installation. This
ensures that all needed components are accessible and that all connected devices seamlessly
connect to the newly migrated instance running on docker.

Supported Version

icom Router Management Server (On-Premises) Version 2025.09.0a

Preparations

Before starting the migration process, a few prerequisites have to be met.

Verify that docker with compose plugin is installed

If you are not sure whether docker is installed correctly or not, enter the following command in the command line:

docker run hello-world

If this command fails, please install docker with the compose plugin as described in the official installation guide. Also make sure that your user is part of the docker group.

Prepare the installation files

Download the installation archive for the iRM Version 2026.05.0 via the cloud platform and
upload it to your machine running the current installation of iRM.

Backup the database

In order to migrate all existing data to the new installation, a dump of said database is needed.
The following command will achieve this for a locally running database:

sudo -i -u postgres pg_dump -d insysicomroutermgmt -f /tmp/insysicomroutermgmt_backup.sql

The database dump will be placed in the directory  /tmp

Migration Process

First time docker installation startup

Start with shutting down the old systemd services:

sudo systemctl stop insysicom-routermgmt.service insysicom-autoupdate.service nginx.service

Change into the directory you saved the new installation files in, and extract them into the newly
created directory for the docker installation:

sudo mkdir /opt/insys-irm 
sudo tar -xzf insys-irm-2026_05_0.tar.gz -C /opt/insys-irm 
sudo chown -R <USER>:<GROUP>/opt/insys-irm

Change into the newly created installation directory and configure the host and db settings in
the .env file. It is important that the db_user defined here matches the database user of the old
database:

cd /opt/insys-irm sudo vim .env

Let the system run its first-time startup:

./start.sh

Wait for the complete startup to finish and stop the system again:

./stop.sh

Migrate existing data

Now that the new system ran once, all needed directories and components have been
initialized. Start with copying the local data from the iRM installation:

find /var/opt/insysicom-routermgmt/ -maxdepth 1 -mindepth 1 -type d -exec 
sudo cp -r {} /opt/insys-irm/data/irm/ \;

Prepare for applying the database dump on the new database:

sudo cp /tmp/insysicomroutermgmt_backup.sql /opt/insys-irm/data/postgres/

Spin up only the Database:

set -a 
source .env 
source images/.irm-env 
docker compose -f docker-compose-db.yaml up -d

And apply the prepared database dump:

docker exec -ti insys-irm-postgres-1 /bin/bash 
psql -U $POSTGRES_USER -d postgres -c 'drop database irm' 
psql -U $POSTGRES_USER -d postgres -c 'create database irm' 
psql -U $POSTGRES_USER -d $POSTGRES_DB < /data/postgres/insysicomroutermgmt_backup.sql 
exit 
docker compose -f docker-compose-db.yaml down

In order for the new system to work with the existing data, the masterkey of the old install needs
to be set in the config of the new system. Execute the following command to print the
masterkey to the cli:

echo "$(grep -oP '(?<=barracuda_master_key: ).*' /opt/insysicom- routermgmt/etc/insysicom-routermgmt.conf)"

Copy the key and set the right value in the following files:

sudo vim ./config/insysicom-routermgmt.conf #replace value of barracuda_master_key 
sudo vim ./config/insysicom-autoupdate.env #replace value of MASTER_KEY

After these steps, the new installation should have inherited all local data like update packages, and all data saved in the database like router data, groups etc.

Configuring the application

TLS

Before starting the new system, it is advised to set the appropriate network mode and place all needed certificates in their respective spot. Set the preferred network mode in the .env file, depending in which mode the previous instance has been running:

sudo vim .env

http

No further configuration needed.

https

If your system has previously been configured with https, you need to place your valid server certificate and its key into the certs directory and name them cert.crt and cert.key

sudo cp /etc/nginx/ssl/insysicom-routermgmt.crt /opt/insys-irm/certs/cert.crt 
sudo cp /etc/nginx/ssl/insysicom-routermgmt.key /opt/insys-irm/certs/cert.key

https-mtls

If your system has previously been configured with added mtls for your devices, then
additionally to the certificates from https, copy your custom certificate authority
c that has been
used for mtls to the certificate directory with the specified name:

sudo cp /etc/nginx/ssl/your_client_authentication-ca.crt /opt/insys-irm/certs/client-ca.crt

Cleanup and start of the new system

As the old installation using the systemd services is now obsolete, these services should be
disabled to not block the new applications from running on certain ports:

sudo systemctl disable insysicom-routermgmt.service insysicom-autoupdate.service nginx.service

Remove any cronjobs connected to the old iRM installation from the following file:

sudo crontab -e # remove lines connected to insysicom-routermgmt

Finally, start the new dockerized application:

./start.sh

You should now be able to access your iRM installation from the same domain or IP as before and see all existing data. Devices that have been online before might need some time to start a reconnection attempt, depending on the time the system has not been reachable.