Previously, the container images both for the Universal GUI and Indicium Application Tier use port 80 to accept traffic. Starting from the release 2025.1.10 and newer, these images will use port 8080. Why this change? This is the first step towards rootless container images. Currently, the containers run under the user root. This is a bad container security practice. If a threat actor manages to get access to the container file-system, it can be abused. Luckily, the ASP.NET container image (which is the base image for Indicium) recently made it possible to run as a non-root user. Implementing this change will take a bit more time, but these changes should go unnoticed. Due to port privileges in the Linux kernel, ports below 1024 require root permissions. This creates an issue when running an application on port 80 without privileges. To permit future non-root users in opening a port, the published port will be moved from 80 to 8080. How will this impact me? If you have a running Univer

Update: the documentation is now available at https://docs.thinkwisesoftware.com/docs/deployment/container_deployment_overview You might have noticed, there is a new menu item in TCP called Thinkwise Containers. Through this menu item it is possible to request login tokens required for downloading Thinkwise container images from the Thinkwise Container Registry. These container images can be used to deploy the Universal GUI and the Indicium Application Tier of the Thinkwise Platform in a new and easy way. But what exactly are containers and container images, how do you use them, and what are the benefits of using container images? What Are Container Images A container image is an application together with all the required dependencies wrapped together into a single image, which basically is a compressed archive. The application that runs from a container image is called a container. Compared to a virtual machine, a container only contains the required dependencies to run the applicatio

The Docker containers are deployed on this page: https://docs.thinkwisesoftware.com/docs/deployment/container_deployment_docker_compose The Indicum container is connected to the database (it is managed in the logs) and the Universal container is also connected in the logs and warnings are given for errors. I've tried many things in YAML including ENABLE_REVERSE_PROXY and FALSE which says "404 page not found". Please help! This is my YAML (but apparently also with the standard and with just about all possible current ones). Original in Dutch - Above translated: Ik heb de Docker containers gedeployed zoals op deze pagina: https://docs.thinkwisesoftware.com/docs/deployment/container_deployment_docker_compose De Indicum container heeft connectie met de database (heb ik gecontroleerd in de logs) en ook de Universal container geeft in de logs geen warnings of errors aan. Ik heb in de YAML veel dingen geprobeerd zoals de ENABLE_REVERSE_PROXY op FALSE te zetten, maar wat ik ook doe, ik krijg i

Hi I'm struggling with the deployment folder. When you define it in the IAM it references my pc. However Indicium is running in the cloud in a container. So it's being saved at a location inside the container. Can I run the container with a mapped directory for example /opt/indicium/deployment that can be mounted to /home/conainter-user/deployment/, is something already foreseen in the container package? With regards to the destination, is OneDrive / SharePoint on the backlog as a destination? Now I don't really have a way to obtain my deployment data.

I'm setting up our new server and we are running databases as containers on different ports. How do I define this in the indicium app settings.. I'm connected via SMSS but I get indicum error that no connection can be made. Is below correct? "Server": "Localhost,1510", System.AggregateException: One or more errors occurred. (A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: TCP Provider, error: 40 - Could not open a connection to SQL Server: Could not open a connection to SQL Server))

Currently, all related running Indicium instances need to be stopped and/or restarted when there is an IAM or Software Factory upgrade (as mentioned in the Deployer and in the documentation). From a system administrator perspective, this is quite some extra work, especially if there are multiple instances looking at the same database. It would be amazing if one or two of the following points can be implemented; Make Indicium aware of upgrades in progress, maybe by adding a table per database containing whether an upgrade is being done or not, to stop scheduled tasks and other things while the upgrade is running, if necessary, mark the instance as unhealthy. Make Indicium aware of an outdated model, if Indicium sees the model is outdated (which needs a restart), mark the instance as unhealthy. This gives the ability to have more self-healing actions through health checks, for example on Azure, AWS, Google Cloud or in containers