Step 4: Servers
Use the Servers step to define the service identity and port values for each application. This replaces the older Advanced Settings approach and reflects the current Portal workflow.
Example of the current Portal step flow highlighting the Servers step in the environment wizard.
Click on the Servers step button to review the server configuration that the installer will use to prepare the environment. The Portal collects these values and writes them into the generated installation package.
Example of the current Servers configuration page showing the service list, service account toggle, and port values.
Servers list
Start in the left Servers panel. This is where the user manages the server entries for the environment.
The first action sequence is:
- Add a server entry when a new host is needed
Important
Do NOT use
localhostas a server name. Use the actual machine name or FQDN of the host where the Core Services will be installed. - Select the server that should be configured
- Remove a server entry that is no longer part of the installation scope.
All remaining sections on this page apply to the currently selected server.
Selected server
After choosing a server, enter the base host values in Selected server:
- Server name
- Install path
- Host core services on this server / - toggle to enable or disable the Core Services on this host. You can ONLY install the Core Services on one host in the environment. If you disable this toggle, the Core Services will not be installed on this host, but you can still install agents on it. There must be at least one server entry in the environment, and the Core Services must be installed on one of the servers.
These values define which host is being configured and where Nodinite files are installed on that host.
Core host TLS
Important
We strongly recommend that the Core Services and agents run with TLS enabled. Running secure HTTPS endpoints is the preferred deployment model for production environments. Review the Hardening guidance for additional TLS configuration and security hardening recommendations.
Next, configure TLS values for the selected host:
- TLS domain name - This is the fully qualified domain name (FQDN) that the Core Services will use for HTTPS bindings. It must match the certificate subject name or subject alternative name (SAN) values.
- Certificate thumbprint - This is the SHA-1 thumbprint of the TLS certificate that is installed on the selected host. The certificate must be valid and trusted by the host where the Core Services are running. Do verify that the certificate is installed in the correct certificate store (Local Computer\Personal or Local Computer\Web Hosting) and that it is not expired or revoked.
Example of the Core host TLS section where the TLS domain name and certificate thumbprint are entered for the selected server.
Example of TLS host and certificate settings that must match the server certificate binding.
Core platform services
After host-level settings are complete, configure Core platform services for the same selected server.
First, decide whether Same account for all Services remains enabled. If it is cleared, enter per-service account values.
Then review and adjust port values for:
Use custom ports only when required by conflicts or policy.
Example of individual service account configuration after clearing the shared service-account option.
Agents on this server
Finish this page by configuring Agents on this server for the same selected host.
Use Choose an agent and Add agent to assign required agents. Remove agent entries that should not run on this server.
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.
For now, you will next configure details for 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 Monitoring Service when possible.
- Avoid custom port values unless there is a real conflict or architecture requirement.
- Keep the certificate model consistent across related services.
- Ensure the TLS certificate thumbprint matches the installed certificate on the target host.
| Service | Recommendation |
|---|---|
| Web API | Use the same account and certificate as the Monitoring Service when possible |
| Monitoring Service | Use the same account and certificate 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 |