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.

Set deferLoading: true on a bootstrap record to lazily initialize step executors.

[
    {
        "deploymentId": "demo",
        "remoteConfiguration": "config.json",
        "deferLoading": true
    }
]

In 3.1.1, this means trigger wiring still happens at startup, but most step execution resources are deferred until first execution.

This reduces initial startup cost for larger deployments.

Practical caveat: runOnce steps are still startup-critical, so the runtime pre-initializes what those need rather than delaying them.

startupPriority

Use startupPriority to control activation order when multiple deployments are present in the same bootstrap file.

[
    {
        "deploymentId": "core-service",
        "remoteConfiguration": "core.config.json",
        "startupPriority": 1
    },
    {
        "deploymentId": "dependent-service",
        "remoteConfiguration": "dependent.config.json",
        "startupPriority": 10
    }
]

Lower numbers activate first.

This is especially useful when one deployment depends on another, such as:

• cross-deployment allowDeploymentAccess
• internal HTTP routing using transport: "inProc"
• shared startup services that should be available before dependents activate

frequency: 0

In 3.1.1, setting frequency to 0 means load configuration once at startup and do not continue polling or watching for updates.

[
    {
        "deploymentId": "demo",
        "remoteConfiguration": "config.json",
        "frequency": 0
    }
]

For URL-based remoteConfiguration, this disables follow-up HTTP polling.

For file-based remoteConfiguration, this disables file watching after the initial load.

That makes it a good fit for packaged or image-based deployments where configuration updates are intentionally done by restart rather than hot reload.

When to Use Which

Use deferLoading when startup latency matters more than first-hit latency.

Use startupPriority when deployment activation order matters.

Use frequency: 0 when you want one-shot startup loading with no ongoing config update checks.