Documentation Index
Fetch the complete documentation index at: https://www.activepieces.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
Waitpoints — durable pause and resume for flow runs
Flows can now pause mid-execution and resume later without losing any state. The execution context is fully persisted so restarts, deployments, or extended wait times do not affect in-progress runs.Two pause types are available out of the box:- Webhook waitpoints — the flow pauses and resumes the moment a specific callback URL is called. The URL is unique to the run, carries the caller’s request body, headers, and query parameters through to the next step, and supports both async and synchronous (respond-when-done) modes.
- Delay waitpoints — the flow pauses until a scheduled timestamp and then resumes automatically, freeing up worker capacity during the wait.
Network Security
Activepieces now ships with a built-in network proxy that protects your automations from network attacks.- One switch to turn it on — set
AP_NETWORK_MODE=STRICTand the protection is active. It’s opt-in today, but in an upcoming release it will become opt-out (on by default). - Allow list for trusted internal services — if a flow legitimately needs to reach an internal API or database, add its address (or a whole subnet like
10.10.0.0/24) toAP_SSRF_ALLOW_LIST. - Works with your corporate proxy — if you already use
HTTP_PROXY/HTTPS_PROXY, Activepieces respects them automatically.
Shared concurrency pools
Projects can now share a single concurrency limit through concurrency pools, giving platform operators finer control over how worker capacity is distributed.- Per-project concurrency — set Max Concurrent Jobs directly in Project Settings > General.
- Shared pools — multiple projects can be grouped into the same pool so they draw from one shared limit instead of each having its own.
-
Embedding support — when provisioning users via JWT, include
concurrencyPoolKeyandconcurrencyPoolLimitclaims to create or reuse a pool automatically. See Provision Users.
Stability & reliability improvements
Major investments in worker architecture, testing, and resilience to ensure more reliable flow execution.Worker Architecture- Complete worker rewrite (worker v2) focused on stability and reliability
- New sandbox process model with improved error handling and resource cleanup
- Queue dispatcher (12 tests) — tests orphaned job handling when a job is dequeued but all waiters have timed out, prevents double-loop spawn during close with in-flight dequeue, verifies single dequeue concurrency control, tests waiter timeout and retry behavior
- Subflow resume (8 tests) — tests the race condition where the engine writes pause metadata to Redis before it’s persisted to DB, verifies Redis fallback when DB is stale, simulates concurrent reads/writes with spy mocks, covers sync endpoint with concurrent Redis updates
- Rate limiter (5+ tests) — tests concurrent job slot allocation, idempotency with concurrent dispatch, per-project isolation so different projects don’t interfere
- Concurrent flow execution — end-to-end test creating 5 concurrent flow runs verifying none get stuck or deadlocked
- Memory lock — verifies mutual exclusion (two concurrent lock acquire calls on same key are serialized)
- Worker polling — tests job execution lifecycle, resilience to invalid job data, null polls, unrecognized job types, mixed valid/invalid sequences
- Sandbox execution — tests sandbox creation, startup, RPC communication, stdout/stderr accumulation, resource cleanup on timeout or memory issues, process cleanup and listener removal
- Process forking — tests execArgv configuration (memory limits, node options), environment variable propagation
- Cache logic — tests cache hit/miss, disk persistence, memory caching, cache invalidation predicates
- Configuration — tests config loading for different container types (WORKER_AND_APP vs WORKER)
- Smoke tests in GitHub Actions — validates health checks and webhook flow execution on AMD64 and ARM64
- Benchmark tests in GitHub Actions — load testing across 6 app/worker configurations measuring throughput, mean latency, P50, P99 (see results)
- Worker gracefully handles invalid job data, null polls, and unrecognized job types
- Sandbox properly cleans up processes, listeners, and resources on timeout or memory issues
- Race condition fixes for subflow resume and user interaction jobs
Platform Admin — full UI redesign
A comprehensive visual refresh across all Platform Admin and Project pages with a cleaner, more consistent interface.Platform Admin- Projects — filter chips, inline edit icons, and cleaner sidebar without branding
- Users — new Role and Last Active columns, dedicated Invite button, and per-row action menus
- Project Roles — switched from table to card-based layout with permission viewing
- Audit Logs — fully enabled with Action, Performed By, Project, and Date Range filters, plus detail slide-over panels with a full JSON payload viewer
- Secret Managers — card-based layout with Hashicorp Vault, AWS Secrets Manager, Cyberark Conjur, and 1Password
- Branding — refreshed page layout
- Automations — renamed from “Flows”, with Type and Owner filters, search, step icon details, status toggles, and favorites
- Connections — Pieces and Owner filters, flow usage count, inline edit and refresh actions
- Runs — updated tab navigation and consistent styling
- Unified tab navigation across Automations, Runs, and Connections
- Platform Admin link added to the bottom of the project sidebar
- Slide-over panels for detail views instead of full-page navigation
- Previous / Next pagination style throughout
- Sidebar header replaced with a “Back to app” link
Dedicated staging environment & improved release process
All changes now go through a dedicated staging environment before reaching production. Every update is validated internally for a minimum of 16 hours before being promoted, ensuring higher reliability and fewer disruptions for our users.- Staging-first deployment — every change is tested in a production-like environment before going live
- Daily production promotions — only validated, stable builds are promoted to production
- Weekly self-hosted releases — predictable, stable releases published every week for self-hosted customers
- Emergency hotfix path — critical fixes can still be fast-tracked to production when needed