Administer and install

Audience: the person who installs and operates Netxus for your Organization. This guide starts after the installation exists: its security roots, database and first Protected Administrator were created with the installation instructions supplied with your release, which take precedence over this summary. It covers configuration in the interface, restart rules, go-live checks and deployment without a cloud provider.

Configure the platform in the interface#

Sign in as the Protected Administrator. None of these settings needs a restart.

1. Users, Groups and Roles (Administration): delegated Group Access Managers can assign only non-administrative Roles.
2. Connector hosts (Administration → Connector hosts): approve the vCenter and Kea hosts that connectors may call.
3. Connector secrets: enter each password or secret in the write-only Secret field under Hosting → Sync connectors and Network → IPAM → DHCP & DNS sync, and enter the HTTPS target secret under Administration → Audit export. A stored secret is never shown again; the page shows only "Stored, updated" with a time and User, "Environment variable" or "Not set". If the connection details change, enter the secret again.
4. SNMP credentials (Facilities → Sensors → SNMP credentials): add v2c or v3 credentials, each bound to a Group, its allowed addresses and an SNMP version. You need Facilities layout management in the Group.
5. Exchange-rate feed (Financial administration → Rate proposals → Configure): enable it per Group.
6. SCIM (Administration → SCIM provisioning): create a connection, then link the existing Groups the identity provider should manage.

Environment-variable alternatives remain available for connector secrets, connector hosts, network sync and SNMP credentials: NETXUS_CONNECTOR_SECRET_*, NETXUS_HOSTING_SYNC_ALLOWED_HOSTS, NETXUS_NETWORK_SYNC_* and NETXUS_SNMP_CREDENTIALS_FILE.

Know which settings need a restart#

Check before going live#

• Backups: follow the backup and restore drill in the instructions issued with your release (contact support@netxussolution.com if you do not have them), and record the recovery point and recovery time you achieved.
• Monitoring: scrape /metrics. Set NETXUS_METRICS_TOKEN_SHA256 to the SHA-256 of a random token and send that token as a bearer token. Alert on /health/ready?strict=1.
• Object store: use a versioned bucket. Add lifecycle rules that expire noncurrent versions after your restore window and abort incomplete uploads. Grant the worker s3:ListBucket, s3:ListBucketVersions, s3:DeleteObject and s3:DeleteObjectVersion for the clean-up jobs for device icons and abandoned uploads.
• Kubernetes: set NETXUS_TRUSTED_PROXY_CIDRS to the ingress controller's pod CIDR so rate limits apply per visitor.
• Front proxy: a proxy in front of the web server must set X-Forwarded-For with $proxy_add_x_forwarded_for or $remote_addr. The API trusts the right-most address, so a proxy that passes the header through lets clients forge addresses.
• Sign-in lock and IPv6: rate-limit addresses are grouped per IPv6 /64, so the holder of a /48 can repeatedly lock a known username through the cross-address lock (50 failures in 15 minutes). A Protected Administrator clears the lock with Clear sign-in lock.
• KMS master key: the default is a local key. You can instead use an HTTPS envelope service over mutual TLS, or the pkcs11-cli provider, which unwraps the master key with an RSA key held in a PKCS#11 hardware security module through OpenSC pkcs11-tool. Wrap an existing key with npm --workspace @netxus/server run kms-wrap-master-key -- --provider pkcs11-cli (or https-envelope) and check the configured provider with npm --workspace @netxus/server run kms-verify-provider. The HSM token must support RSA-OAEP with SHA-256; a token that cannot (SoftHSM2 2.7, for example) needs NETXUS_KMS_PKCS11_OAEP_HASH=sha1, and you must re-wrap the master key after changing it. Test with your HSM before production.

Deploy on-premises without a cloud provider#

Netxus does not need AWS. "S3" means the S3 API, served on the same host by SeaweedFS: the installer and the Compose profiles start it pinned and with versioning enabled. SeaweedFS supports what Netxus uses: bucket versioning, presigned upload and download, checksum-bound uploads with mismatches rejected, version IDs, and listing, reading and deleting specific versions. It also accepts a lifecycle rule, but Netxus does not rely on lifecycle expiry there and prunes old object versions itself.

Run without internet access#

1. Container images: on a connected machine, pull the third-party images, which are pinned by digest: PostgreSQL, SeaweedFS, ClamAV and Mailpit. Build the Netxus images (api, worker, web, migrate, init); that build needs npm, Debian and PostgreSQL package-repository access. Save everything into one archive, copy it across and load it on the target.
2. Virus signatures: the ClamAV container normally updates itself over the internet. Offline, run a private signature mirror on a connected machine, copy the signature files across on a schedule and serve them to the scanner. Check how your pinned ClamAV image loads signatures before going live. Uploads stay pending until the scanner answers.
3. Time: run chrony against an internal NTP source. Sessions, leases and TOTP codes depend on a correct clock.
4. Features that need outbound access can be left unconfigured offline: the ECB exchange-rate feed, AWS and Azure Hosting connectors, an external identity provider (OIDC or SCIM), an external SIEM and Let's Encrypt. Online licence verification also needs outbound access: the installation must verify its licence regularly (seven-day freshness, then a fourteen-day grace period; see the Core guide), so contact support@netxussolution.com before an air-gapped deployment. Local-network features such as vCenter and Kea on your own network and SNMP polling do not need internet access.

Boundaries: this guide summarizes configuration, not a complete installation or recovery runbook. Backup custody, security roots and database recovery follow the instructions issued with your release.