System Requirements
What an EmberNet edge node needs, and how to size a deployment.
Operating system
Edge nodes run EmberRTOS, Fireball Industries' own immutable Linux distribution. It is not a supported configuration to install the platform onto an arbitrary Linux distribution; the OS and the platform are provisioned together.
Two variants share one base and differ only in kernel:
| Variant | Kernel | Use it for |
|---|---|---|
| EmberRTOS (Standard) | Stock | Everything that isn't hard real-time |
| EmberRTOS RT | PREEMPT_RT, 6.12 or later | Deterministic control loops with a bounded latency requirement |
The real-time kernel is a per-machine choice at provisioning time, not a separate
product. Choosing it raises the minimum kernel to 6.12, since that is where
PREEMPT_RT landed in mainline.
Hardware
Minimum, single node
| Component | Requirement |
|---|---|
| CPU | 4 cores, x86_64 or ARM64 |
| RAM | 8 GB |
| Storage | 128 GB SSD |
| Network | 1 Gbps Ethernet |
Recommended, multi-node
| Component | Requirement |
|---|---|
| CPU | 8 or more cores, x86_64 |
| RAM | 16 to 32 GB |
| Storage | 256 GB or more, NVMe |
| Network | 1 to 10 Gbps Ethernet, bonded where available |
| Nodes | 3 or more for replicated storage |
Three nodes is not an arbitrary recommendation. Cinder defaults to three replicas, and a three-replica volume on a two-node cluster can never reach a healthy state. See Storage.
Storage disks
Give the platform a separate data disk from the OS disk. Capacity is expanded by attaching another data disk, never by growing the OS disk, and a node provisioned with a single disk is painful to expand later.
Validated platforms
- OnLogic: Helix, Factor, and Karbon series rugged computers
- Velasea: Iron Link series edge servers, NVRs, and storage systems
- Custom x86_64 or ARM64 hardware meeting the specifications above
For real-time workloads, validate the specific hardware rather than trusting the class. Measured worst-case latency varies more with firmware and chipset than with core count. EmberRTOS RT covers what to measure.
Network
| Requirement | Detail |
|---|---|
| Outbound HTTPS | Port 443, for mesh enrollment and cloud sync |
| DNS | Ability to resolve public names |
| NTP | Time synchronization, required for certificate validation |
| Inbound ports | None |
EmberNet requires no inbound firewall ports. Every connection is established outbound through the zero-trust mesh. See Zero-Trust Networking.
NTP is easy to overlook and produces confusing failures when it's wrong. A node with significant clock skew fails certificate validation, which surfaces as enrollment or connectivity errors rather than as a time problem.
Browsers
The dashboard runs in Chrome 90+, Firefox 85+, Edge 90+, and Safari 14+. There is no client to install.
Sizing
| Deployment | Devices | Shape | Hot retention |
|---|---|---|---|
| Small | 1 to 50 | Single node, 8 GB RAM, 4 cores, 128 GB | 7 days |
| Medium | 50 to 500 | 3 nodes, 16 GB RAM, 8 cores, 256 GB each | 30 days |
| Large | 500+ | 5 or more nodes, 32 GB RAM, 16 cores, 512 GB+ each | 90 days |
Hot retention is the number that moves with deployment size, because it is bound by local disk. Warm and cold retention are platform defaults and do not scale per node. See Configuration Reference.
Large deployments benefit from dedicating nodes to storage rather than mixing storage and compute on every node.
Next steps
- Installation Guide: provisioning a node
- Configuration Reference: settings after install
- EmberRTOS Overview: the OS underneath