Step 4: Servers
Use the Servers step to define each server in the Environment: which server hosts the Core Services, which TLS certificate they use, the service identity and port of every Core Service, and which agents run where. This step replaced the older Advanced Settings tab.

Example of the Portal step flow with the Servers step highlighted in the Environment wizard.
Click the Servers step button to review the server configuration. The Portal writes these values into the generated installation package.

Example of the Servers configuration page with the server list, the service account toggle, and the port values.
Understanding the Server Model
On Windows Server, every Core Service (Web Client, Web API, Log API, Logging Service, Monitoring Service, and MCP Server) is its own IIS web site with its own port. One server in the Environment hosts all Core Services; any server, including that one, can also run agents. At every install and update, the CLI looks up the TLS certificate by its subject and binds it to the Core Services web sites.
Hostname (SNI), Certificate subject"] PORTS["fa:fa-sliders Core platform services
identity and port per service"] end subgraph "Nodinite Core Services Server (Windows Server)" STORE["fa:fa-vault Certificate stores
LocalMachine\WebHosting
LocalMachine\My"] CLI["fa:fa-terminal CLI, at every
install and update"] subgraph SITES["IIS web sites, one port each"] WC["fa:fa-globe Web Client"] WA["fa:fa-cloud-sun Web API"] LA["fa:fa-cloud-arrow-down Log API"] LS["fa:fa-hard-drive Logging Service"] MS["fa:fa-watch-fitness Monitoring Service"] MCP["fa:fa-plug MCP Server"] end end HOST -->|"Subject"| CLI PORTS -->|"Ports, identities"| CLI STORE -->|"Valid certificate
matching the subject"| CLI CLI -->|"HTTPS binding with SNI"| SITES style HOST fill:#2678BD,color:#fff style PORTS fill:#2678BD,color:#fff style STORE fill:#3F827B,color:#fff style CLI fill:#E47528,color:#fff style WC fill:#93d16d style WA fill:#93d16d style LA fill:#93d16d style LS fill:#93d16d style MS fill:#93d16d style MCP fill:#93d16d
Diagram: the Portal values (blue) and a valid certificate from the server's certificate stores (teal) go to the CLI (orange), which creates one IIS web site per Core Service (green) with its own port and binds the certificate. See Secure Your Nodinite Installation with HTTPS/TLS for the certificate requirements.
Servers list
Start in the left Servers panel, where you manage the server entries of the Environment:
Add a server entry for each host.
Important
Don't use
localhostas a server name. Use the actual machine name or FQDN of the host.Select the server to configure.
Remove a server entry that is no longer part of the installation.
All remaining sections on this page apply to the selected server.
Selected server
After you select a server, enter its base values in Selected server:
- Server name
- Install path
- Host core services on this server: enables the Core Services on this host. Only one server in the Environment can host the Core Services. When the toggle is off, the server can still run agents. The Environment needs at least one server, and one of them must host the Core Services.
These values define which host you configure and where the Nodinite files are installed on it.
Core host Configuration
Important
Run the Core Services and agents with TLS enabled; HTTPS endpoints are the production deployment model, and OAuth 2.0 / OIDC requires them. Review the Hardening guidance for certificate requirements and hardening recommendations.
Tell the installer which TLS certificate the Core Services use on the selected host:
| Field | What to enter | Required |
|---|---|---|
| Hostname / Server Name Indication (SNI) | The fully qualified domain name (FQDN) that users, agents, and API clients use to reach the Core Services, for example nodinite.contoso.com. It must match the certificate subject or a subject alternative name (SAN). |
✅ Yes, for HTTPS |
| Certificate subject | The certificate subject or SAN, for example *.contoso.com or nodinite.contoso.com. |
✅ Recommended |
| Certificate thumbprint | The SHA-1 thumbprint of one exact certificate, without spaces. | ⚠️ Only when you must pin one certificate |
Identify the Certificate by Subject, Not Thumbprint
Certificates are renewed often, and every renewal gives the certificate a new thumbprint. A thumbprint in the Portal pins one exact certificate, so you must update it after every renewal. The subject stays the same when a certificate is renewed, so the configuration keeps working.
During every install and update, the installer looks in the LocalMachine\WebHosting and LocalMachine\My certificate stores on the server for a valid certificate that matches the configured subject (or the thumbprint, when you set one) and binds it to the Core Services web sites. After a certificate renewal, install the renewed certificate on the server and run the update package again; with a subject configured, you don't need to change anything in the Portal.
Leave Certificate thumbprint empty unless a policy requires you to pin one exact certificate, for example when several valid certificates on the server match the same subject.

Example of the Core host Configuration section: Hostname (SNI), Certificate subject, and the optional Certificate thumbprint.
For a test environment without a CA, see Development Certificates; for TLS errors after the installation, see TLS Troubleshooting.
Core platform services
After the host settings, configure Core platform services for the same server.
First, decide whether Same account for all Services stays enabled. When you clear it, enter an account per service. Every account needs the Logon as a Service right; the Monitoring Service account also needs DCOM Local Activation permission, and the Core Services need a configured MSDTC (Monitoring Service prerequisites). The defaults come from Service Account Defaults in Step 2.
Then review the port of each service. Each port belongs to one IIS web site, so it must be free on the server and open in the firewall for its callers; the Network and Firewall Overview is the one home for these rules. Ports in examples, such as 40000–40004, are examples only. With TLS configured, consider port 443 for the Web Client: it's the HTTPS default, so users open https://nodinite.contoso.com/ without a port. HTTPS works on any other port too, but then the port must be part of the URL.
| Service | Install page with the Portal values and verification |
|---|---|
| Web Client | Install the Web Client |
| Web API | Install the Web API |
| Log API | Install the Log API |
| Logging Service | Install the Logging Service |
| Monitoring Service | Install the Monitoring Service |
| MCP Server | Install MCP Endpoint |

Example of individual service account configuration after clearing the shared service-account option.
Keep the MCP Server Stopped
The MCP Server card has the option Keep the MCP Server stopped. When it is selected, the installer deploys the MCP Server web site and files but leaves its application pool stopped, also after an IIS reset or a server restart. A stopped MCP endpoint after an install or update is then by design. Select it when you don't use the AI Assistant or external MCP clients yet; clear it and run the package again when you want to start the MCP Endpoint.

Example of the Core platform services section: one port per service, and the Keep the MCP Server stopped option on the MCP Server card.
Agents on this server
Finish the server by configuring Agents on this server.
Use Choose an agent and Add agent to assign the Monitoring Agents and Log Agents that run on this host. Remove agent entries that should not run here.

Example of adding an agent to the selected server in the Agents on this server section.

Example of removing an agent entry from the selected server configuration.
You configure the details of each agent in the Agents step.
Recommended Configuration
- Keep the default account model unless a policy requires separation.
- Use the same identity for the Web API and the Monitoring Service when possible.
- Change the proposed port values only for a real conflict or architecture requirement.
- Identify the TLS certificate by its subject; set a thumbprint only when you must pin one exact certificate.
- Install a valid certificate with that subject or SAN in
LocalMachine\WebHostingorLocalMachine\Mybefore you run the package.
| Service | Recommendation |
|---|---|
| Web API | Use the same account as the Monitoring Service when possible |
| Monitoring Service | Use the same account as the Web API when possible |
| Log API | Keep the default pattern unless a specific security requirement exists |
| Web Client | Keep the default service configuration unless a custom requirement exists |
| Logging Service | Keep the default pattern unless a specific security requirement exists |
| MCP Server | Keep the default pattern unless a specific security requirement exists |