Run the following command to start an i-net Clear Reports Server Docker Container:

docker run -d -p 9000:9000 -e CONF_listener__port=9000 --name reporting inetsoftware/i-net-clear-reports

• i-net Clear Reports 26.4: latest, alpine-26, alpine-26.4 (latest can be the next major version, new license key may be required)
• i-net Clear Reports 25.10: alpine-25.10
• i-net Clear Reports 25.x: alpine-25
• i-net Clear Reports 24.x: alpine-24
• i-net Clear Reports 23.x: alpine-23
• i-net Clear Reports 22.10: alpine-22.10 (last supported version)

The i-net Clear Reports Docker Container should be pre-configured using either a configuration properties file or environment variables. Either way, a local installation with the specific setup should be created first. Using the Maintenance module a backup of the configuration can be created and the configuration properties file in there can be used as a basis.

Note: To have the container fully set up on startup you have to specify at least the following properties: CONF_listener__port and CONF_licensekey

Note: In private cloud environments you have to set the property CONF_serverURL as well. It is recommended to set this property in other environments too.

A configuration file can be added by using a volume or any other means that adds a specified configuration to the container. The default configuration file can be used or a different one can be set using an environment variable. See Environment Properties Matrix.

version: '2.1'

services:

    reporting:
        image: 'inetsoftware/i-net-clear-reports:latest'
        restart: 'always'
        ports:
            - 9000:9000

        environment:
            - DEFAULT_PROPFILE=/tmp/defaultConfiguration.properties
            - DEFAULT_CONFIG=User/Default
 
            # Set the externally visible server url (un-comment and insert the correct url)
            #- CONF_serverURL=https://hostname.company.com:9443/
 
            # Set the license key (un-comment and insert the full license key)
            #- CONF_licensekey=...
 
            # Run the application on a pre-determined port for easier mapping
            - CONF_listener__port=9000
 
            # Customize an option, e.g. the theming colors
            - CONF_theme__themecolors={"@base-color":"#0a89dd","@primary-color":"#42a7ca"}
 
            # Enable logging, route log to the container log-file
            - CONF_log__engine=true
            - CONF_log__file=/dev/stdout
 
            # Location for automatic backups
            - CONF_BackupLocation=/home/reporting/.i-net software/reporting_User_Default/backup

For sensitive configuration values like license keys, Docker secrets provide a more secure alternative to environment variables. Secrets are automatically loaded from the /run/secrets/ directory and made available as environment variables.

Note: The container automatically loads all files from /run/secrets/. For files starting with conf_ (case-insensitive), the CONF_ prefix is kept uppercase and the rest is converted to lowercase. For example:

• A secret file named conf_licensekey will be available as the environment variable CONF_licensekey
• A secret file named conf_listener__port becomes CONF_listener__port
• For other secret files, the entire filename is uppercased

Important: For configuration keys with mixed-case (like serverURL), you must use explicit mapping because automatic loading converts everything after CONF_ to lowercase. For example:

• Config key serverURL requires environment variable CONF_serverURL (with uppercase URL)
• Automatic loading of conf_serverurl would create CONF_serverurl (all lowercase), which is incorrect
• Use explicit mapping: Set SECRET_CONF_serverURL environment variable to load from /run/secrets/conf_serverurl and export as CONF_serverURL

Important: The container runs as a non-root user (typically UID 1000/GID 1000). Secret files must be readable by the container's group. When creating secret files on the Docker host, ensure they have the correct permissions. If the container shows a permission error, it will display the actual GID that needs read access.

To use Docker secrets, you need to:

1. Create the secret file on your Docker host (e.g., /etc/docker/secrets/conf_licensekey)
2. Set proper permissions so the file is readable by the container's group (typically GID 1000)
3. Configure the secret in your docker-compose.yml file

For configuration keys that are all lowercase (like licensekey), you can use automatic loading:

version: '2.1'

services:
    reporting:
        image: 'inetsoftware/i-net-clear-reports:latest'
        restart: 'always'
        ports:
            - 9000:9000
        secrets:
            - conf_licensekey
        environment:
            - DEFAULT_PROPFILE=/tmp/defaultConfiguration.properties
            - DEFAULT_CONFIG=User/Default
            - CONF_listener__port=9000
            # The license key will be automatically loaded from /run/secrets/conf_licensekey
            # and available as CONF_licensekey environment variable

secrets:
    conf_licensekey:
        file: /etc/docker/secrets/conf_licensekey

For configuration keys with mixed-case (like serverURL), you must use explicit mapping:

version: '2.1'

services:
    reporting:
        image: 'inetsoftware/i-net-clear-reports:latest'
        restart: 'always'
        ports:
            - 9000:9000
        secrets:
            - conf_serverurl
        environment:
            - DEFAULT_PROPFILE=/tmp/defaultConfiguration.properties
            - DEFAULT_CONFIG=User/Default
            - CONF_listener__port=9000
            # Explicit mapping for mixed-case: SECRET_CONF_serverURL loads from /run/secrets/conf_serverurl
            # and exports as CONF_serverURL (preserving the mixed case)
            - SECRET_CONF_serverURL

secrets:
    conf_serverurl:
        file: /etc/docker/secrets/conf_serverurl

Note: Make sure to set proper permissions on the secret files on the Docker host. The container runs as a non-root user (typically GID 1000), so secrets must be readable by that group. To find the actual GID, check the container logs if there's a permission error - it will show the required GID. Alternatively, you can check with:

# Find the container's GID (replace 'reporting' with your container name)
docker exec reporting id -g

Then set the permissions accordingly (replace 1000 with the actual GID if different):

CONTAINER_GID=1000  # Use the GID from the command above if different
mkdir -p /etc/docker/secrets
chmod 750 /etc/docker/secrets
chgrp $CONTAINER_GID /etc/docker/secrets
echo "your-license-key-here" | tee /etc/docker/secrets/conf_licensekey
echo "https://hostname.company.com:9443/" | tee /etc/docker/secrets/conf_serverurl
chmod 640 /etc/docker/secrets/conf_licensekey
chmod 640 /etc/docker/secrets/conf_serverurl
chgrp $CONTAINER_GID /etc/docker/secrets/conf_licensekey
chgrp $CONTAINER_GID /etc/docker/secrets/conf_serverurl

Note: When using Docker Swarm secrets (not file-based secrets), Docker automatically handles permissions. However, if you're using file-based secrets in docker-compose, you need to set the permissions manually as shown above.

If there are more specific requirements, such as a pre-filled user database, a custom container should be created

Using the following compose example, you can create a server that is started without any permission restrictions and can be used without further authentication using the public URL context.

version: '2.1'

services:

    reporting:
        image: 'inetsoftware/i-net-clear-reports:latest'
        restart: 'always'
        ports:
            # Not setting a host port allows to use --scale, but the external port varies
            - 9000:9000

        environment:
            # Using the User Default configuration
            - DEFAULT_CONFIG=User/Default
 
            # Set the license key (un-comment and insert the full license key)
            #- CONF_licensekey=...
 
            # Run the application on a pre-determined port for easier mapping
            - CONF_listener__port=9000
 
            # Only guest account is active. Activate webapi.
            - CONF_authentication__settings=[{"provider":"guest"}]
            - CONF_plugins__activated={"webapi.core":true}

The following Dockerfile will create a user admin with the password password in a new container.

FROM inetsoftware/i-net-clear-reports
 
# Switch to root user for installation
USER root
 
# Tools
RUN apk add --update linux-pam
 
# grant pam permissions to everybody
# Create User that we can log in with
RUN chmod +r /etc/shadow \
    && adduser -D -g "User" admin \
    && echo admin:password | chpasswd \
    && ln -s "/etc/pam.d/base-password" "/etc/pam.d/reporting"
 
# Switch back to product user
USER reporting

To bundle a docker container with a MongoDB persistence using Docker Compose, the following docker-compose.yml script can be used as a starting point:

version: '2.1'

services:

    reporting:
        image: 'inetsoftware/i-net-clear-reports:latest'
        restart: 'always'
        ports:
            # Not setting a host port allows to use --scale, but the external port varies
            - 9000:9000

        environment:
            # Using the System/Default config is mandatory in cloud persistence environments
            - DEFAULT_CONFIG=System/Default
 
            # Set the externally visible server url (un-comment and insert the correct url)
            #- CONF_serverURL=https://hostname.company.com:9443/
 
            # Set the license key (un-comment and insert the full license key)
            #- CONF_licensekey=...
 
            # Run the application on a pre-determined port for easier mapping
            - CONF_listener__port=9000
 
            # Do not force the application to overwrite a previously imported configuration
            # or other instances using the same MongoDB will have their configuration modified
            - FORCE_IMPORT_CONFIG=0
 
            # Set up the connection the MongoDB persistence
            - inet_persistence=mongodb://root:example@mongo:27017/reporting

    mongo:
        image: mongo
        environment:
            MONGO_INITDB_ROOT_PASSWORD: example
            MONGO_INITDB_ROOT_USERNAME: root
        restart: always

Note: The parameter FORCE_IMPORT_CONFIG should be set to 0 so that the configuration is imported only once versus every time the container is started. This way the configuration may be persisted and re-used on subsequent restarts or in a scaled environment.

Note: Depending on the specific environment there may be some more options that have to be set. Please have a look at the Environment Properties Matrix.