Cloud or On-Prem: Deploying Robot Calibration in Air-Gapped Factories

How Reforge's architecture handles both connected and isolated environments — and what the trade-offs actually are.

One of the most common questions in enterprise robotics evaluations is whether software requires a cloud connection. For many factory environments, the answer determines whether a product is even viable.

Air-gapped facilities — production floors with no external internet access — are not edge cases. They're the norm in defense manufacturing, pharmaceutical production, some automotive plants, and any facility where operational security requires network isolation. If your calibration software requires an API call to a cloud server, these customers can't use it.

Reforge supports both deployment models. The default path uses a cloud API for model generation. A local deployment path uses a containerized C++ binary for the same computation, with no network dependency. This post explains how both work, what the trade-offs are, and how to choose.

The default: cloud API

Both paths share the same SDK and produce identical models. The only difference is where model generation runs.

The standard Reforge workflow sends calibration data to a cloud API for model identification. The flow is:

1. Data collection runs locally on the robot through the Reforge SDK. The robot executes the calibration routine and the SDK captures the sensor data. This step has no network dependency — it runs entirely on the local compute connected to the robot.

2. Model generation runs on the cloud API. The calibration data is uploaded, the system identification algorithm processes it, and a calibrated model is returned. This is the step that requires connectivity.

3. Deployment runs locally. The calibrated model downloads to the local compute and integrates with the robot's control pipeline through the SDK. Once deployed, the model runs locally with no ongoing cloud dependency. The controller operates on the local machine — latency-sensitive control loops never touch the network.

The cloud path is the default because it simplifies deployment. No local GPU or high-performance compute is required for model fitting. Updates to the identification algorithms roll out automatically. And model management — versioning, storage, retrieval across a fleet — is handled server-side.

The local path: containerized C++ binary

For facilities that cannot connect to external networks, the same model generation runs locally.

The local deployment packages the system identification algorithms as a C++ binary inside a container. The container runs on standard compute hardware — no GPU required. The architecture is CPU-based, which means the compute requirements are modest: any modern x86 or ARM system with sufficient memory can run the model fitting.

The local workflow differs from the cloud path only at step 2:

1. Data collection — identical to the cloud path. Runs locally through the SDK.

2. Model generation — runs on the local compute instead of the cloud API. The containerized binary processes the calibration data and produces the same calibrated model. The algorithms are identical. The outputs are identical.

3. Deployment — identical to the cloud path. The model integrates locally through the SDK.

The result is a fully self-contained calibration pipeline that never leaves the local network. Data stays on-premises. Models stay on-premises. The robot's control pipeline runs locally.

Architecture decisions

Several architectural choices enable both deployment models without maintaining two separate codebases.

CPU-only computation. The model identification algorithms are CPU-based. This was a deliberate choice. GPU acceleration would improve fitting speed for very large datasets, but it would also impose hardware requirements that many factory compute environments can't meet. CPU-only means the local deployment runs on whatever compute is already on the factory floor — industrial PCs, edge servers, standard rack-mounted hardware. No special procurement.

ARM and x86 support. The containerized binary runs on both ARM and x86 architectures. Factory compute environments are not uniform. Some run standard x86 servers. Others — particularly edge deployments close to the robot controller — run ARM-based industrial PCs. Supporting both architectures means the local deployment doesn't constrain the customer's hardware choices.

Container isolation. The local binary runs inside a container, which provides environment isolation without requiring the customer to manage dependencies, system libraries, or build toolchains. The container image is versioned and tested as a unit. Deployment is a container pull (or, in fully air-gapped environments, an image file transfer) followed by a run command.

Identical algorithms. The cloud API and the local binary run the same identification code. This is a non-negotiable architectural constraint. If the local path produced different models than the cloud path, validation would require testing both, and customers would need to qualify each deployment model independently. Identical code means identical outputs. A model validated through the cloud path will be identical to one generated locally from the same data.

What you give up with local deployment

The two paths are functionally equivalent for model generation. The differences are operational.

Operational trade-offs between cloud and local deployment. The model outputs are identical — the differences are in how you manage the pipeline.

Fleet-level model management. The cloud API provides centralized storage and versioning of calibrated models across a fleet. If you're running 50 robots across three facilities, the cloud API gives you a single view of which robots are calibrated, which models are current, and which units are due for recalibration. Local deployment puts model management on the customer's infrastructure.

Algorithm updates. Cloud deployments receive algorithm improvements automatically. Local deployments require a container image update, which follows the customer's own change management process. For some facilities, this is a benefit — controlled update cycles are a requirement, not a limitation. For others, it means lagging behind on improvements until the next scheduled update window.

Compute provisioning. The cloud API runs on infrastructure sized for the workload. Local deployment requires the customer to provision sufficient compute. For kinematic calibration (small datasets, fast fitting), the requirements are minimal. For vibration compensation (larger datasets, longer fitting), the compute time scales with dataset size. On typical factory compute, this means minutes to tens of minutes rather than the seconds the cloud API delivers.

Licensing

Local deployment uses a local license model. The license is tied to the deployment and does not require network validation after initial activation. This addresses the air-gap requirement completely — once activated, the system operates with no external dependencies.

Licensing terms are currently being finalized with market feedback. The intent is straightforward pricing that doesn't penalize customers for choosing one deployment model over the other.

How to choose

The decision is usually straightforward:

Cloud API if your facility has internet access and you want the simplest deployment with automatic updates and centralized fleet management. This is the default recommendation for most customers.

Local deployment if your facility requires air-gapped operation, your security policy prohibits sending calibration data to external servers, or your change management process requires controlled software update cycles.

Hybrid if you operate multiple facilities with different network policies. Some facilities use the cloud API. Others run locally. The models are interchangeable because the algorithms are identical.

In practice, most customers start with the cloud API during evaluation and initial deployment. Customers with air-gapped requirements validate locally from the start. The transition between models is an infrastructure change, not a software change — the SDK interface is the same regardless of where model generation runs.

The bottom line

Reforge's calibration pipeline works in both connected and isolated environments. The cloud API is the default path — simplest to deploy, automatically updated, centrally managed. The local path — containerized, CPU-only, ARM and x86 — delivers identical results with no network dependency.

The architecture was built for factory environments where the compute and connectivity constraints aren't negotiable. If your facility can't connect to the internet, that's a deployment detail, not a dealbreaker.

Reforge Robotics builds open-source motion control software that makes robot calibration fast, affordable, and deployable anywhere.