> ## Documentation Index
> Fetch the complete documentation index at: https://docs.neuro-tech.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Complete first-run setup

> Configure persistence, networking, identity, backups, and services

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

## Configuration sequence

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Configure XMPP">
    Enable client-to-server and server-to-server listeners as required. Federation needs public DNS, a valid certificate, and reachable port `5269`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="Choose optional services">
    Configure ledger participation, roster defaults, mail relay, visual theme, and operator notifications only where the deployment needs them.
  </Step>
</Steps>

## 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:

```dns theme={null}
_xmpp-client._tcp.example.com. 3600 IN SRV 0 5 5222 neuron.example.com.
_xmpp-server._tcp.example.com. 3600 IN SRV 0 5 5269 neuron.example.com.
```

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:

```bash theme={null}
curl --fail --show-error https://neuron.example.com/
```

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.