---
title: "Runner environment and limits | Lansweeper Platform"
slug: "runner-environment-and-limits"
description: "Learn the Flow Builder runner limits for memory, execution time, webhook payload and response sizes, synchronous timeouts, and concurrent executions."
status: "new"
updated: 2026-10-01T18:06:37Z
published: 2026-10-01T18:06:37Z
canonical: "docs.lansweeper.com/runner-environment-and-limits"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lansweeper.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Runner Environment and Limits

Workflows execute in isolated, containerized Node.js environments with specific resource allocations and execution constraints. Understanding these limits helps you design Workflows that perform reliably within the runner's boundaries.

## The runner environment

Executions of Workflows (and test runs of Workflows) execute in isolated Node.js containers with distinct filesystems and memory. Two executions of the same Workflow run in distinct isolated environments. Workflows currently run using Node.js version 22.

## Runner limitations

### Memory allocation

The Workflow runner is allocated 1 GB of RAM for execution by default. If your Workflows run out of memory, optimize how they process data and avoid holding large datasets in memory.

### Execution time limitations

A Workflow runs for up to 15 minutes. If you have large datasets to process, break the data into smaller chunks. You can process chunks in parallel by sending them to another Workflow, or process them across several subsequent executions using a [loop](/docs/loop).

## Webhook limitations

### Webhook request size limitations

Webhook payload size is limited to 6 MB. 6 MB is generally large enough to handle most JSON, XML, or other webhook payloads.

If the payload you need to process exceeds 6 MB (for example, large images or PDFs), save the large file to a file storage system first (Dropbox, Amazon S3, Azure Files, and so on) and send *metadata* about the file in your webhook request. Your Workflow can then use the metadata to fetch the file for processing.

### Synchronous webhook response size limitations

When a webhook is invoked synchronously, the response contains the results of the last step of the Workflow. For example, if the last step returned a PDF file, the webhook response is a PDF file. The runner writes the response to a file in cloud storage and responds with an HTTP 303 (Redirect) to the stored object.

Step results have a maximum size of 500 MB. If the results you generate exceed 500 MB, write the file to a file storage system (Dropbox, your own Amazon S3 bucket, and so on) and return metadata about the file instead.

### Synchronous invocation timeouts

A webhook request times out after 30 seconds. Webhook requests to [synchronous triggers](/docs/trigger-workflows#synchronous-and-asynchronous-invocations) (triggers that wait until the execution finishes running before responding) must complete their work in under 30 seconds.

### Webhook rate limiting and concurrent executions

The number of executions that can run at the same time is limited. If that many executions are already running and an additional request is received, the requester receives a 429 "too many requests" response.

When an execution starts, the first log line includes the number of executions that are currently running.