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.

Licensing changed substantially in opscotch 3.1.1.

The previous embedded license model still works in 3.1.1, but the recommended model is now hierarchical runtime licensing. Licenses are issued through https://licensing.opscotch.co, can be delegated down a chain of authority, and can be managed without rebuilding packages.

Opscotch 3.1.1 standardizes app packaging around the packager app. This is the supported way to produce production-ready Opscotch app packages, and it is the path to future-safe packages going forward.

The packager is no longer just a CLI-shaped tool. It is an Opscotch app with an HTTP API.

Version 3 of opscotch introduces a small but powerful "preprocessor" called doc for JavaScript processors. The doc functions allow you to add documentation and add programatic declarations of what inputs and outputs your step expects and returns. It's a way to validate and perform type checking, and also declares your expectations to callers.

See the doc documentation here

Prior to version 3.1.0 of opscotch, you could only receive text content from the HTTP trigger i.e. json or text like. Version 3.1.0 now lets workflows receive raw binary uploads. The new context.getStream() call gives you direct access to the byte stream.