Resilient Edge Computing for Remote Sites

The Challenge

Remote offices, branch locations, and forward-operating sites rarely have the luxury of a proper data center: limited power, limited physical space, and a network connection that can’t be counted on to stay up. Traditional high-availability infrastructure assumes you can throw a dedicated storage array and a stable link at the problem — neither of which is realistic when your entire footprint is a couple of small servers in a room that also serves three other purposes.

The usual result is a choice between running without any redundancy at all, or over-building a site with more hardware and complexity than it can support.

How Basalt Solves It

Basalt runs a real, resilient compute cluster in as small a footprint as two nodes — enough to protect critical workloads without demanding a rack’s worth of hardware, dedicated storage appliances, or a specialized on-site engineer. The two nodes replicate data directly between each other in real time, so the site gets meaningful redundancy without needing a separate external storage array or a third node just to act as a tie-breaker.

If one node fails, the platform detects it, safely establishes that the failed node is truly down before acting, and automatically restarts the affected workloads on the surviving node — restart-class high availability that keeps the site running through a hardware failure rather than requiring someone to drive out and fix it before operations can resume.

None of this depends on a healthy link back to headquarters. Basalt separates centralized oversight from local execution, so workloads keep running, security policy keeps enforcing, and failover keeps working entirely on-site even when the connection back to central management is intermittent or completely down. When connectivity returns, the site reports its status and reconciles with central policy automatically — no manual re-enrollment, no rebuilding the environment from scratch.

And because it’s the same platform under the hood, a small site isn’t locked into staying small. As requirements grow, the same infrastructure can expand into a larger, more scalable storage architecture — without swapping platforms, re-training staff, or re-architecting what’s already running.

Key Capabilities

• Runs in as little as two nodes — real redundancy in a minimal physical and power footprint, suited to sites without room for a full rack or dedicated storage hardware.

• Local data replication between nodes — data mirrors directly between the site’s own nodes in real time, delivering resilience without an external storage array.

• Automatic workload restart on failure — if a node goes down, its workloads come back up automatically on the surviving node, with safeguards in place to prevent conflicting or unsafe restarts.

• Built for unreliable connectivity — local operations, security enforcement, and failover all continue on-site regardless of whether the link to central management is up, intermittent, or down entirely.

• Automatic resync when connectivity returns — the site reports its state and reconciles with central policy on its own once the link comes back, without manual rebuild.

• Grows with the site — starts as a compact two-node deployment and can scale into a larger, more capacity-rich storage architecture on the same platform as needs increase.

The Outcome

Teams running remote and branch locations get dependable uptime without needing to staff a specialist on-site or over-invest in hardware the location doesn’t have room for. A node failure becomes a non-event handled automatically rather than an outage that waits on a truck roll, and a site that starts small can grow into something larger without a rip-and-replace down the road.

When those sites grow into regional infrastructure, the same platform handles data center consolidation. For the architecture underneath, read the platform overview.