Topic
This article describes NinjaOne Relay for disconnected and air-gapped environments.
Environment
NinjaOne Platform
Description
NinjaOne Relay provides endpoint management capabilities for fully disconnected and air-gapped environments. Relay enables extended control for inventory management, patching, reporting, and scanning endpoints that would otherwise go unmanaged. Click the sections below for more information.
- NinjaOne Relay Server
- Operating Modes
- Listeners and Network Surfaces
- User Interface (UI)
- Security
- Workflows
- Data Durability
- Compliance
- Additional Resources
NinjaOne Relay Server
The NinjaOne Relay server extends NinjaOne coverage to endpoints that can't connect directly to NinjaOne's SaaS platform. NinjaOne Relay runs as a service on a managed host and acts as a trusted intermediary. A small platform-specific agent on each endpoint reports to the relay. From there, the data either gets sent to NinjaOne (Mode A) or stays local and is shown through the operator user interface (UI) in Modes B, C, or D. Multiple relays can share a single Certificate Authority via a peer-trust configuration, allowing larger or redundant deployments to spread agents across several relays that all trust one another.
Operating Modes
The operating_mode config key, set at install time, determines which subsystems start and which network surfaces open. Every mode uses the same agent mTLS transport. What changes between them is what flows above that layer, and in which direction. Refer to the following chart for details on operating modes. Click the mode name for more details.
| Mode | NinjaOne Sync | Operator UI | Bundle Subsystem | Typical Use |
|---|---|---|---|---|
| A-Bridged | On (bi-directional) | Optional | None | Standard NinjaOne integrated deployment |
| B-One-way (diode) | Push down only | Required (both) | Producer + Consumer | Hardware data diode between trust boundaries |
| C-Air gap | Off | Required | None | Stand-alone, fully disconnected enclaves |
| D-Sneakernet pair | D-conn side only | Required (both) | Producer + Consumer | Two-relay pair with operator-carried media. |
Mode A: Bridged
For customers whose relay host can reach NinjaOne and who prefer to drive endpoints from the NinjaOne platform they already use. NinjaOne API access is needed only at install, but you can revoke permissions afterward, and the relay keeps syncing from its cached role mappings.
Mode B: One-way: diode-protected pair
For environments that need NinjaOne to push files and jobs across a trust boundary without anything coming back. NinjaOne pairs two relays through a hardware data diode (Guard); the isolated relay communicates with its endpoints but cannot reach back to NinjaOne or to the connected relay.
Mode C: Air-gap: fully stand-alone
For enclaves with no path to NinjaOne at all. The relay is the entire management surface, driven through the local UI.
Mode D: Sneakernet pair: connected ↔ air-gap ↔ isolated
For a true physical air-gap, bridged by sealed media, an operator carries between two paired relays: the connected side packages bundles, the isolated side replays them, and returns results the same way.
Listeners and Network Surfaces
The NinjaOne Relay runs on Windows Server 2019+, macOS 12+, and modern Linux, with a FIPS variant available for regulated deployments. It exposes up to three inbound TLS listeners, depending on mode. Agents always reach the relay on port 8443; the other two are mode-conditional. The only outbound connection a relay makes is HTTPS to the NinjaOne API, and only from the relay that faces NinjaOne (Mode A), plus the connected side of the Mode B and Mode D pairs. The air-gapped relay (Mode C) and the isolated relays make no outbound connections at all. The following chart describes each listening option.
| Listener Port | Mode | Description |
|---|---|---|
| 8443 | All | Agent API (mTLS) Always on. Built-in CA; enroll, checkin, inventory, jobs/result, cert/renew, files, OCSP responder. |
| 8444 | B, C, and D | Operator UI + Command API React and Mantine SPA, session cookies, RBAC, MFA, and optional CAC/PIV. |
| 9443 | D only | Bundle Import (mTLS) Signed and encrypted sealed-bundle ingest with per-peer replay protection. |
User Interface (UI)
Modes B, C, and D feature a polished operator console embedded directly in the relay binary. There are five top-level workspaces:
Status: Worker health, queue depths, audit-chain verification.
Inventory: Per-endpoint hardware, software, and network history.
Library: Packages, patches, SCAP content, compliance baselines, staged files, and bundles.
Configuration: Users and roles, authenticators, TLS, and external PKI.
Targeting: Pick a target set and an action, then watch a live job grid.
Security
NinjaOne Relay contains the following security features:
Transport and Identity
Mutual TLS between every agent and the Relay, using a built-in ECDSA P-256 Certificate Authority generated on first start. Each agent receives a 90-day client certificate via a one-time enrollment token. Certificates auto-renew 30 days before expiry. NinjaOne Relay supports revocation via CRL and an RFC 6960 OCSP responder with AIA embedding. Agents pin the relay CA's fingerprint during first enrollment (TOFU) and reject any subsequent CA mismatches.
Operator Authentication
The operator UI supports local accounts with Argon2id password storage, TOTP MFA with three-tier recovery (per-user codes, administrator reset with two-admin co-sign, and a break-glass key generated at install). Optional CAC/PIV authentication validates the full cert chain against operator-imported trust anchors with real-time OCSP and CRL revocation (hard-fail by default; soft-fail and internal- OCSP-responder overrides available for air-gap).
Defense in Depth
IP allow/deny lists, GeoIP country filtering, and token bucket rate limiting per endpoint and globally. IPv6 source addresses are aggregated to /64 by default (RFC 4291 host boundary), so a hostile peer with a routed prefix cannot exhaust the per-key bucket cap. X-Forwarded-For is honored only when the peer is on the trusted-proxy list. Agent-supplied inventory data is HTML-escaped before it renders into NinjaOne WYSIWYG fields, which closes the stored-XSS surface.
Tamper-Evident Audit
NinjaOne Relay records every enrollment, certificate issuance, revocation, job dispatch, configuration change, and administrative action in a SQLite-backed audit log with a parallel hash chain ( SHA-256(canonical(row) ‖ prev_hash) ). A verification endpoint walks the chain and surfaces the first break, suitable for incident response forensics and cross-relay attestation in Mode D.
Credentials at Rest
NinjaOne Relay stores enrollment tokens as SHA-256 hashes, and both the Command API key and the enrollment token auto-rotate on a configurable schedule. NinjaOne Relay stores the key in a TEXT_ENCRYPTED secure custom field with automation READ_ONLY permission. Column-level secrets (bundle private keys, MFA secrets) are wrapped with a Key Encryption Key generated at install and stored with a chmod 0600 file alongside the database. All secrets on disk are 0600; the Linux service runs as a dedicated user under systemd hardening.
FIPS 140-3 Option
An optional FIPS build mode restricts TLS cipher suites and validates key types for regulated deployments. The bundle envelope supports both Ed25519/X25519 (default) and ECDSA-P256/ECDH-P256 (FIPS-clean) suites; in FIPS mode, password hashing falls back from Argon2id to PBKDF2-HMAC-SHA512 with 600,000 iterations.
Workflows
Beyond the original inventory and command primitives, Modes B, C, and D add the following workflows for the everyday operator tasks that previously required custom NinjaOne automations:
- Patches: import patch packages, deploy to targets, track per-endpoint install status, surface installed-patch baseline in inventory.
- Software packages: install/uninstall/verify with per-platform commands; package list as inventory.
- SCAP scanning: manage scan content, engines, and tailorings; trigger scans; ingest ARF/XCCDF results; per rule findings surfaced in the UI.
- Compliance baselines: named bundles of required patches and packages, plus a SCAP profile; assign to endpoints; an endpoint × baseline grid shows compliant/noncompliant/unknown at a glance.
- Bundle transport (Mode D): the producer side packages everything above as signed bundle ops; the consumer side replays them.
Data Durability
Crash-safe by default. All authoritative states persist in a WAL-mode SQLite database with synchronous commits and 0600 permissions, including issued certificates, endpoint records, inventory snapshots, the audit log, enrollment tokens, staged files, the NinjaOne role cache, bundle queues, user accounts and sessions, SCAP results, and compliance baselines. A sudden host reboot loses at most whatever was mid-commit; SQLite rolls that back on reopen. No special shutdown procedure is required. In-memory state is ephemeral and safe to lose on restart, and periodic cleanup jobs (retention, snapshot pruning, token and file expiry) run automatically with no operator intervention.
Compliance
Three compliance artifacts ship with the product: an Application Security and Development (ASD) STIG attestation, a NIST SP 800-53 (rev 5) controls matrix, and an operator hardening guide. The audit log retains 90 days by default and is exportable.NinjaOne Relay holds no customer data beyond endpoint inventory and job history; all of it remains on the customer's infrastructure unless explicitly synced to NinjaOne (Mode A).
Additional Resources
For more information about NinjaOne Relay, refer to NinjaOne Endpoint Management: System Requirements and Compatibility.