Installation and Deployment

Deploying the digital twin has three parts: the server (backend), a PostgreSQL database, and the web app, which sits behind a web gateway (for example, IIS). Most of this lesson happens outside the interface; after installation, you use the server console to create the project, the key, and the administrator account.

Prerequisites

Step by step: Windows with IIS (the recommended method)

1. Prepare. Open PowerShell as Administrator; if script execution is blocked, run Set-ExecutionPolicy -Scope Process Bypass for that session only. Create an empty database in PostgreSQL. The package's scripts first verify file integrity against a hash list before doing anything else.
2. Install the server. In the package's backend folder, run the Install-Backend script with the install folder (-InstallDir), the database password (-DbPassword), the site's public address exactly as the user types it in the browser (-PublicOrigin, with https://), and the NSSM path (-NssmPath). The script generates the production settings file from a template, sets the session cookie to secure if the address starts with https, copies the license file if it is missing, and creates a Windows service with automatic startup.
3. Install the web app. In the frontend folder, run the Install-Frontend script with the site name, site path, host name, port, and the -EnableArrProxy option. If the server is on a different machine, pass its address with -BackendUrl.
4. HTTPS. In IIS Manager, under Site → Bindings, add a valid certificate and a secure binding, and set up the http-to-https redirect there as well.
5. Verify the installation. The service should be Running; the site should open and let you log in; and the browser console (F12) should show no WebSocket connection error. In the server console, the Overview tab should show RUNNING.

   

Linux and Docker

• Linux (systemd): the Linux deployment script, run as root, creates a dedicated service user and a systemd service, and prepares the logs, data, uploads, maps, and config folders. Edit the production settings file (the database password is read from the DB_PASSWORD environment variable), place the license file yourself next to the application file, and start and enable the service. The service is created with systemd security restrictions and automatic restart on failure.
• Docker: set the POSTGRES_PASSWORD variable before running; Compose will not start without it. Two services come up: PostgreSQL and the server; data (the database, logs, uploaded files, maps, and settings) live in separate volumes, and the app runs as a non-root user. The web app is not part of Compose and is deployed separately behind a web gateway. The license file is not inside the image; coordinate how to place it in the container with the ARG deployment team.

Key settings in the production file

The service only runs with an external settings file; every setting the server needs must be in that same file. Other operational settings (the Security, Logging, Backup, Queue, and other categories) are viewed and changed after installation from the server console's Settings tab (lesson C4).

Step by step: initial setup after installation

1. Log into the console. Open the console address and log in with the admin account. On the very first startup, if no system user exists yet, the Users sub-tab shows the System Setup - Create Administrator Account window; coordinate initial console access with the ARG deployment team.
2. Create the project. Under «System Design» ← «Projects» (System Design → Projects), click + Add Project and create the project.
3. The Master key. In API Key Management, make sure the project has an active key at the Master (Full Access) level; if not, generate one with Generate New Key. Without an active key, web logins are rejected with "API key not found for project".
4. The administrator account. In the admin-creation window, fill in First Name *, Last Name *, Username *, Password *, and Confirm Password *, and click Create Administrator Account.
5. Finish in the web app. Log into the web app with this same account and complete the general configuration from «تنظیمات» ← «تنظیمات پروژه» (Settings → Project Settings) (lesson C3).

Tips and common mistakes

• A 500.19 error on every page means URL Rewrite is not installed; a 404 on API requests means proxying is off in ARR; a 502.3 means the server is not up.
• The page opens but no live values arrive: check the WebSocket feature in IIS and that the allowed-origins address exactly matches the browser's address, and restart the service.
• Console login does not persist: on an http site, the secure cookie setting must be off.
• A service created with Windows' built-in java service wrapper stops after about 30 seconds; build the service with NSSM instead.
• Do not edit the license file; any change invalidates it. Log the expiration date in your maintenance calendar, since expiry takes effect on the next restart (for example, after a Windows update).
• Web app build settings (such as the product profile) are fixed at build time; changing them requires a new build.

Summary

• Java 17+, PostgreSQL, a license file, and (on Windows) IIS with URL Rewrite, ARR, and WebSocket.
• The site's public address must exactly match one of the allowed WebSocket origins.
• An invalid license means the server shuts down completely at startup.
• After installation: project → Master key → administrator account → project settings.