Skip to main content
The first-run wizard is available only from localhost. Complete it from the Neuron host before exposing the service publicly.

​
Configuration sequence

1

Choose persistence

Select the encrypted internal object database for a single-node deployment, or a supported external database such as MongoDB when multiple runtime nodes must share data. Record where database encryption keys are stored.
2

Review personal-data processing

Read the personal-data disclosure and confirm that the deployment’s purpose, retention, and access policies match it. This is an operational decision, not a checkbox to automate blindly.
3

Restore or configure backups

Restore an existing backup if this server replaces another instance. Otherwise enable automatic backups, choose retention, and place copies outside the server’s program-data disk.
4

Configure the network edge

If the host is behind a gateway, configure port forwarding for the protocols you use. Prefer explicit mappings and verify them from outside the local network.
5

Assign the domain and DNS

Set the canonical domain name. Configure address records and, when applicable, XMPP SRV records, mail MX/SPF records, and certificate validation records.
6

Configure XMPP

Enable client-to-server and server-to-server listeners as required. Federation needs public DNS, a valid certificate, and reachable port 5269.
7

Establish the Neuron identity

Apply for or import the Legal Identity used by the Neuron. This identity anchors signed contracts and service assertions made by the server.
8

Choose optional services

Configure ledger participation, roster defaults, mail relay, visual theme, and operator notifications only where the deployment needs them.

​
DNS verification

At minimum, the canonical host name must resolve to the public address that reaches the Neuron. For XMPP federation, publish SRV records for the services you expose. A typical shape is:
Use your DNS provider’s syntax and include the final dot only when its UI expects a fully qualified name.

​
Verify from outside

Local success does not prove that NAT, DNS, certificates, or firewall rules work externally. From a separate network, verify:
Also test XMPP federation if it is enabled. The administrative Ports view shows local listeners; it cannot confirm an Internet path through an upstream firewall.

​
Secure the administration surface

  1. Create a named administrator account.
  2. Store its credentials in an approved password manager.
  3. Restrict administration routes with the Web Application Firewall.
  4. Create narrower roles for operators, support staff, MCP clients, and applications.
  5. Confirm that a non-administrator account cannot reach administrative pages.

​
Before going live

  • Trigger one backup and restore it in a non-production environment.
  • Confirm certificate expiration and renewal behavior.
  • Send a test operator notification.
  • Inspect event and exception logs.
  • Record the package versions and configuration source used for the deployment.