Edge install

Eldric on the edge —
Pi, NUC, Jetson.

A single-node Eldric runtime ships with 5.0 GA for small edge hardware: the local data lives on the device, queries are served locally, and writes buffer up to the central cluster when the link is back. This page covers what's supported, what the hardware needs, and how to install on each platform.

When to use the edge runtime

Three deployment shapes.

The minimal edge install is appropriate for three kinds of deployment:

• Branch office or field clinic. A single physical site that needs Eldric locally — chat, knowledge-base search, agent invocation — even when the link to the central data centre is intermittent.
• Industrial cell or factory line. A workstation or edge gateway at the line that runs perception, classification or policy execution against the IoT worker; the central cluster handles training, aggregation and reporting.
• Autonomous platform. A robot, AGV or inspection drone that needs cognition on-board because the radio link is not reliable. Soft real-time, edge-deployed, no cloud dependency.

For a full Eldric deployment — multi-tenant, multi-worker, with training, comm and media workers — use the standard Linux server install instead.

Minimum hardware

What the edge node actually needs.

The minimal-runtime package targets small, low-power edge boxes. The supported floor at GA:

• 4 GB RAM minimum (8 GB recommended for knowledge-base loads above a few hundred documents).
• 32 GB storage minimum (more if you intend to hold a sizeable local knowledge base or store-and-forward buffer for a long disconnect).
• ARM64 or x86-64 CPU. The platform ships ARM packages for Pi 4 / generic ARM64 / Jetson, and x86-64 packages for everything else.
• Network reachability to a central cluster for initial pairing and pre-trained model pull. Once paired, the edge node operates offline.

Hardware below this floor (e.g. Pi Zero, Pi 3, BeagleBone) is not officially supported at GA. The platform may run there in degraded form; we don't certify it.

Raspberry Pi 4

The lightest path.

On a Raspberry Pi 4 (4 GB or 8 GB) running Raspberry Pi OS (64-bit, bookworm or newer), the install path is:

curl -fsSL https://repo.eldric.ai/install.sh | sudo bash
sudo apt install eldric-aios-minimal
sudo systemctl enable --now eldric-aios

The minimal package omits the workers you don't need on an edge node (science, training, NOVA, swarm, comm, media, IoT industrial protocols) and keeps the kernel, controller, data, edge and knowledge-base modules. Footprint sits at about a quarter of the full distribution.

On first boot, the chat shell comes up at https://<pi-ip>/chat. The first signup becomes the local administrator. To pair the Pi with a central cluster for shared models and store-and-forward, run the pairing step from the Admin Console (Settings → Edge → Pair with cluster) — your central cluster's administrator hands you a short token to paste in.

Intel NUC

Branch-office class.

An Intel NUC (any model with 8 GB+ RAM and 256 GB+ storage) is a comfortable fit for a branch office or a small department. Standard Fedora / RHEL / Ubuntu install:

curl -fsSL https://repo.eldric.ai/install.sh | sudo bash
sudo dnf install eldric-aios-minimal     # Fedora / RHEL
# or
sudo apt install eldric-aios-minimal     # Ubuntu / Debian
sudo systemctl enable --now eldric-aios

On a NUC with the extra headroom, you can also install the full eldric-aios package instead and run a complete single-node Eldric. The minimal package is only the right choice if RAM is constrained or the node's role is genuinely edge-only.

NVIDIA Jetson

GPU at the edge.

NVIDIA Jetson (Orin / Orin Nano / Xavier) is the right choice when the edge workload includes vision encoding, the xLSTM forecast or policy daemon, or local model fine-tuning. The Jetson package includes the CUDA-side workers in addition to the minimal core:

curl -fsSL https://repo.eldric.ai/install.sh | sudo bash
sudo apt install eldric-aios-minimal eldric-aios-jetson
sudo systemctl enable --now eldric-aios

The Jetson edge node runs the xLSTM daemon (port 8884) locally — useful for robotics or inspection-drone deployments where the radio link to a central cluster is intermittent. Pair with a central cluster for model updates and aggregated reporting.

Offline operation

When the link drops.

Once paired with a central cluster, an edge node can run fully offline indefinitely. The platform buffers writes locally — telemetry events, conversation history, document uploads — and replays them to the central cluster when the link returns. Reads (chat, knowledge-base search, agent invocation) hit the local data; if the question genuinely needs a model only the central cluster has, the edge node queues the request and answers when the link is back.

The store-and-forward path is unconditional: a write at the edge always gets accepted locally. There's no "central cluster unreachable" failure to handle in your code; the operational distinction between online and offline disappears below the API surface.

Honest scope

What edge doesn't try to do.

• Multi-tenant on the edge node. The minimal package supports one tenant per edge node; for multi-tenant edge you need the full eldric-aios package on hardware that fits it.
• Training workloads at the edge. The training worker is not in the minimal package. Train centrally; deploy fine-tuned small models to the edge.
• The science worker's 140+ external APIs. Science work centralises naturally; the edge node typically doesn't need those.
• Sub-millisecond inference on Pi-class hardware. The Pi can run small models fast enough for classification, short completions and policy execution; it is not microsecond-deterministic. Hard real-time control belongs in the motor controller, not in Eldric — see robotics.

Next.

The general install flow — including macOS workstations and full Linux servers — lives on get started. The post-install setup is on first run. Common install errors are on install troubleshooting. For platform-on-your-domain (the principle behind why edge deployment matters), read apply Eldric to your domain.