Workflow Pricing and Limits

Edgenivo bills Workflows usage across three resources:

• Workflow Events: Every state transition in a workflow run is persisted as an event. See Events for more details.
• Workflow Data Written: The amount of data written to managed persistence for workflow state and event logs, including stream data.
• Workflow Data Retained: The amount of data stored per month in managed persistence.

Edgenivo bills each resource based on usage. Hobby includes monthly allowances for Workflow Events and Workflow Data Written. Workflow Data Retained is not available on Hobby, and Edgenivo bills Pro usage on demand.

You can inspect the amount of Workflow Data Written for a specific workflow run by navigating to the workflow details on the Workflows page in the dashboard. Edgenivo calculates Workflow Data Retained based on the amount of data written and the retention period. For example, writing 1 GB and having a retention period of 1 month would result in 1 GB-month of retained data.

Functions invoked by Workflows continue to be charged at the existing compute rates. We recommend using Fluid compute with Workflow for reduced costs and higher performance.

Workflow uses Edgenivo Queues to orchestrate workflow runs. Edgenivo bills Queues usage at standard rates, see Edgenivo Queues pricing for more details.

Every state transition in a workflow run is persisted as an event. The full list of events is available in the Workflow SDK documentation.

As an example, a normal step function execution produces three events: step_created, step_started, and step_completed. For every time a step re-tries due to a transient error, a step_retrying event is also created.

Edgenivo bills Workflow Data Retained for the retention period of each run, which depends on your team plan. For retention periods, how long Edgenivo keeps run data, run metadata retention, and how to delete run data sooner, see Data Retention.

The following limits apply to all Workflow runs. Events per run and Steps per run are the defaults for the Node.js runtime, and the QuickJS runtime lifts both.

Workflow runs your workflow function on the Node.js runtime by default, which caps each run at 25,000 events. Runs that start on the experimental QuickJS runtime with snapshotting enabled are exempt from that cap, so a run can record more events and execute more steps than the table above lists. Every other limit on this page still applies, including payload size, entity storage, replay duration, and the rate limits below.

To opt in:

1. Set the WORKFLOW_VM environment variable to quickjs for your project.
2. Leave WORKFLOW_SNAPSHOT_THRESHOLD unset, or set it to a positive integer. QuickJS snapshots workflow state every 1,000 events by default. A value of 0 turns snapshotting off, and those runs keep the 25,000 event cap.
3. Redeploy your project.

A run records its runtime and snapshot policy when it starts, so the exemption covers only runs that start after you redeploy. Runs already in progress keep the limits they started with, and runs that already failed with MAX_EVENTS_EXCEEDED don't resume on their own. Start those runs again.

QuickJS is experimental, and your workflow function sees a different set of globals: Intl, WebAssembly, and Atomics are unavailable, and crypto.subtle methods throw. Your step functions are unaffected and keep full Node.js access. For the complete list of differences, see the QuickJS runtime documentation.

Requests include any event creation or stream write operation, as well as any operation for reading events, stream chunks, metadata, or event data. For any request made from your deployment, exceeding the rate limit will automatically re-try with backoff. This includes the initial request to start the workflow. If the call to start() does not throw an error, the workflow will eventually start and run to completion or failure. This means hitting the rate limit will not cause your workflow to fail, but it will slow down the rate at which your workflows run. A rate-limited write that records a step's result is retried for as long as the function invocation runs, so the step doesn't run again or use up one of its retries.