Compute where the data lives. Move data when you can.

Opscotch 3.1.5 introduces Linux ARM64 support and marks a major milestone for the platform: Opscotch workloads can now run consistently across cloud servers, laptops, industrial hardware, and low-cost edge devices like Raspberry Pi.

This is more than platform support.

It means Opscotch can now operate where traditional cloud-first automation platforms fundamentally struggle: disconnected environments, field operations, remote infrastructure, and systems that cannot depend on permanent connectivity to a central control plane.

Most automation platforms assume:

• persistent network connectivity
• centralized orchestration
• cloud-managed execution
• always-reachable infrastructure

Real-world operations often look nothing like that.

Machines move in and out of coverage. Remote sites lose connectivity. Equipment operates for days without reliable access to central systems. Data is generated far away from where it is ultimately consumed.

Opscotch was designed around portable workloads and local execution. Linux ARM64 support now extends that model onto low-cost and industrial edge hardware.

The result is a different operational pattern:

• workloads execute locally
• capability boundaries are enforced locally
• packages are verified locally
• data collection continues offline
• synchronization happens opportunistically

The runtime does not require permanent connectivity to operate.

What “edge” actually means

There are really two kinds of edge environments:

1. Network edge Systems operating outside reliable network coverage.

2. Physical edge The places where work actually happens:

   • farms
   • factories
   • construction sites
   • mobile equipment
   • remote facilities

Both create the same requirement:

Execute locally. Persist locally. Synchronize when possible.

A real deployment model

Consider agricultural equipment operating across large rural properties.

A Raspberry Pi mounted inside the equipment runs Opscotch workflows locally:

• collecting telemetry
• monitoring attached devices
• processing operational data
• buffering outbound events

The machine may spend the entire day outside reliable network coverage.

When it returns near a depot, workshop, or barn and reconnects to a local network:

• queued data synchronizes upstream
• updated .oapp packages are downloaded
• workloads are updated atomically

The workload continues operating regardless of whether connectivity exists.

This is a fundamentally different assumption from cloud-dependent orchestration systems.

Portable workloads, not environment-specific builds

Opscotch packages are portable artifacts.

The same .oapp package can:

• run on a Raspberry Pi in the field
• run on an ARM server in a factory
• run in Docker in a datacenter
• run on a developer laptop

The operational contract stays consistent across environments:

• same package
• same workflow
• same bootstrap model
• same capability restrictions

Develop locally. Deploy anywhere.

Why ARM64 matters

Linux ARM64 support in 3.1.5 opens Opscotch to an entirely different class of deployment targets:

• Raspberry Pi 64-bit systems
• industrial ARM hardware
• fanless edge systems
• low-power field devices
• ARM cloud infrastructure

These devices are:

• inexpensive
• physically deployable
• power efficient
• operationally practical for distributed environments

Opscotch workloads can now move from centralized infrastructure directly onto the machines and environments generating the data.

Control-plane independence

One of the biggest architectural differences in Opscotch is that workloads are self-contained.

Opscotch does not require:

• a permanent SaaS control plane
• cloud-managed orchestration
• continuous remote supervision

Capability restrictions, trust decisions, package validation, and workload execution all happen locally inside the runtime.

That matters at the edge because disconnected operation stops being a failure mode and becomes a normal operating condition.

OTA updates without rebuilding deployments

Opscotch packages are signed, portable deployment artifacts.

Edge devices can:

• periodically check for updated packages
• download new versions when connectivity exists
• apply updates atomically
• continue running locally afterward

This enables practical over-the-air deployment patterns for disconnected infrastructure without introducing permanent dependency on centralized execution.

Hardware on the edge

Edge hardware is often low powered ARM64 devices like Raspberry Pi.

Opscotch 3.1.5 supports Linux ARM64 natively.

For Raspberry Pi deployments:

unzip linux-opscotch-agent-linux-arm64-3.1.5.zip
./opscotch-agent

The same runtime model also applies across:

• Linux x86-64
• Windows x86-64
• macOS Apple Silicon
• Linux containers

The workload portability contract remains the same across all supported environments.

Edge-first automation

Edge computing is not just “smaller cloud”.

It requires different assumptions:

• connectivity is intermittent
• synchronization is delayed
• workloads must survive independently
• infrastructure must tolerate isolation

Opscotch is designed around those realities.

Compute where the data lives. Move data when you can.