BREAKING CHANGE: The startup arguments for the test runner agent runtime have changed. Testing against production agent runtimes requires a production license.

Opscotch 3.1.6 updates the test runner to exercise the same packaging and licensing path used by current Opscotch deployments.

The test runner now injects configuration through the secrets endpoint, includes production license keys for production test coverage, and can deploy the packager and licenser Opscotch apps into the running Opscotch agent as part of the test flow.

BREAKING CHANGE: Opscotch 3.1.6 removes legacy v1 licensing completely.

3.1.5 was the final release that supported v1 licensing. While the 3.1.5 agent runtime continued to support apps packaged with a legacy license, the remaining hard dependency was in the test runner, which still needed a legacy license to start.

From 3.1.6 onward, legacy v1 licensing is completely removed.

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.

Opscotch 3.1.5 brings true write-once-run-anywhere capability. From this release, opscotch publishes native binaries and runs on Linux x86-64, Linux ARM64, Windows x86-64, and macOS Apple Silicon.

Opscotch is now a genuinely portable platform.

Opscotch 3.1.1 adds three bootstrap controls that matter directly for startup behavior:

• deferLoading
• startupPriority
• frequency: 0

Together they let you trade off eager initialization, activation ordering, and remote-configuration update behavior.

Opscotch 3.1.1 adds two distinct ways for deployments in the same runtime to talk to each other. They solve different problems, and it helps to treat them as separate tools rather than variants of the same feature.

Opscotch 3.1.1 adds OPSCOTCH_SECRETS_FROM, a startup-time way to load environment-variable values from an external source.

This is intentionally much narrower than a full secret-manager integration. The runtime reads a single blob once at startup, parses it as environment-style properties, and uses matching keys to override environment-variable lookups and bootstrap ${VAR} substitutions.

Opscotch 3.1.1 expands bootstrap networking so an external-host call can be routed internally instead of going over the network.

This is done by combining:

• allowExternalHostAccess[].transport = "inProc"
• allowHttpServerAccess[].inProcOnly = true

Opscotch 3.1.1 expands bootstrap workflow.outputs so you can define additional named outputs and route metrics to them from workflow JavaScript.

This is a metric-routing feature. In the current runtime, the workflow-facing API added here is context.sendMetric(outputId, ...).

Opscotch 3.1.1 adds trigger.tcp, allowing workflows to bind to a bootstrap-declared server and process framed TCP input.

The feature is intentionally narrow: the current trigger supports delimiter-based framing or fixed-length framing, with optional batching controls for delimiter-based traffic.