A placement decision before an installation

Activepieces connects triggers and actions in visual workflows. We considered it for a low-frequency research queue: collect a source, prepare a draft, and leave publication for a person. Our first decision was where that workflow could run without disrupting an occupied host. This is a documented capacity assessment, not a hands-on Activepieces performance review.

The official Docker Compose installation guide, rechecked on November 6, 2026, specifies at least two vCPUs and 4 GB RAM and uses an application, worker, PostgreSQL and Redis. That is installation guidance, not a measurement of a particular workflow. A product's ability to connect to a model also does not include the model provider's usage, account access or operating cost.

The small host failed the initial fit check

On October 29 our read-only audit recorded one vCPU, 955.7 MiB of total memory and approximately 473.4 MiB available on a host already delivering a network service. About 13.7 GiB of disk space remained. No container runtime was installed. The machine fell below both the CPU and memory guidance before we assigned any additional workload.

A 30-second passive window showed at most 2% CPU busy time, no new OOM kills, no swap-in/out pages and no recorded interface drops or errors. This was a quiet observation, not proof of peak-hour capacity. Low current CPU use did not create several gigabytes of memory or establish that a new worker could coexist with the existing service.

We chose not to install Activepieces there. No image was pulled, no application was started and no proxy, firewall or route was changed for the assessment. The sanitized placement-study JSON preserves the dated measurements and decision without exposing host identifiers or private configuration.

Review the version you intend to deploy

Our configuration audit used release 0.92.3-hotfix.2, not an unspecified latest branch. Its Compose file declared five worker replicas, and its worker configuration used a concurrency default of five. Those settings were a reason to review the proposed worker count; they were not an observed 25-job throughput result. Future versions may differ, so inspect the exact Compose file and worker configuration again before using them.

Network coexistence needs its own check. Docker's documentation explains that bridge networking creates host firewall rules; with its default iptables configuration it can also enable forwarding and alter forwarding policy. Selecting an unused web port does not isolate those changes. An installation on a network host therefore requires more than an application-port check.

A larger machine was a pilot candidate

A separate workstation audit found 20 logical CPUs, approximately 62.4 GiB RAM and 37.9–38.5 GiB available during its sample. It also recorded about 5.07 GiB of occupied swap and small ongoing swap activity. We proposed an isolated guest with four vCPUs, 8 GiB RAM and 40 GiB disk, one worker and concurrency one. That was a conservative planning allocation including the guest operating system, not measured Activepieces usage or Docker overhead. The guest and Activepieces were not deployed by this assessment.

What a useful pilot still needs to answer

Record the chosen version, edition and exact components. Keep provider credentials separate from exported workflow examples.
Measure startup, idle use and one representative flow, including a failed connection and a retry.
Pause before publication and verify that rejection actually prevents the external action. A preview screen is not sufficient evidence of an approval gate.
Compare existing-service response and error observations during the run. A successful workflow does not prove that shared services were unaffected.
Test recovery with a disposable item. Confirm what happens when a worker stops after sending an external request but before recording completion.

Choose Activepieces when connecting existing services is the main job and someone can maintain the runtime and permissions. Our audit supports rejecting the small occupied host and considering a separate pilot. It does not provide a runtime RAM figure, workflow latency, authenticated social-network integration or a completed deployment.

Turn the proposed research queue into a failure test

The capacity assessment above remains the reason not to install on the occupied small host. If a separate pilot is later authorized, use this original queue fixture before connecting live publication. It is a proposed test design: no Activepieces instance, flow, approval, retry or downstream write was executed for this extension.

Define one review item and one permitted effect

The job is to register a source revision for editorial review. The only permitted effect in the proposed trial is a record in an isolated test sink. Keep email, CMS publishing, X posting and model calls disconnected. The fields below are our fixture vocabulary, not a native webhook or piece schema.

First delivery: event_id=evt-001, source_id=source-001, revision=r1, text=Draft A, review=pending.
Business key: join source identifier and revision, giving source-001:r1. Keep the delivery event ID separately. A second delivery can have a new event ID while referring to the same review item.
Proposed review record: business key, source text or its fingerprint, observed delivery IDs, flow version, run references, review decision and sink receipt. Do not fill the receipt from a successful canvas preview.

In a candidate flow, validate the required fields, find the matching review item, and route a new item, a matching repeat or a conflicting repeat separately. Activepieces documents table read/create/update actions that can support an inspectable prototype. A lookup followed by creation is not proof of atomic uniqueness under concurrent runs; require the sink's own uniqueness or idempotency behavior before claiming duplicate protection.

Use this sequence as an acceptance script

New source: submit the first-delivery fixture. Expect one r1 review item in pending state and no publication effect.
Same delivery again: submit the identical event. Expect the same business item, without a second item or a repeated paid drafting step.
New delivery ID, same revision: change only the event ID to evt-002. Expect a delivery observation attached to the same item; event-ID deduplication alone does not satisfy this case.
New revision: submit evt-003 with revision=r2 and text=Draft B. Expect a distinct r2 review item. It must not inherit any approval attached to r1.
Conflicting repeat: reuse the r1 business key with different text. Expect an explicit conflict/manual-review branch, preserving the previous record. Do not silently treat a changed payload as the already reviewed version.
Decision boundary: exercise pending, reject and approve decisions against disposable items. Pending and reject must produce no accepted-output record. Approve may write only to the test sink, never to a real publication destination. Repeating an approval must not create a second accepted record.

Then test the awkward failure: let the isolated sink accept the r1 write, but make the flow step report a timeout before completion is recorded. Retry with the same business key. The expected check is one accepted record, with both attempts inspectable; a green retried step alone is insufficient. This failure has not been injected here. After serial checks, submit two copies concurrently to expose a lookup/create race that serial testing cannot detect.

Separate checkpoint recovery from external effects

The current durable-execution documentation describes reusing checkpointed step outputs and rerunning unfinished work. An external system can have accepted a request before the workflow records its completion. Treat idempotent writes as a separate requirement, not a property established by that checkpoint description. Match the behavior to the pinned pilot release; these current docs do not update or validate the historical configuration audit above.

The current retry reference distinguishes retrying from the failed step, which retains earlier outputs, from rerunning on the latest published version. Record which strategy and flow version you used. Do not compare an old and a revised flow as though they were the same trial. We did not connect MCP or invoke either strategy.

Also distinguish approval of an automation from approval of a source item. The documented Flow Approvals feature reviews changes before a sensitive flow is published and requires the Enterprise/Cloud Environments plan. It is not evidence that every content item pauses for a reviewer. The per-item pending/reject/approve branches above still need their own implementation, permissions and actual tests in the chosen edition.

Keep a decision record before paying for more automation

Retain the exact fixtures, flow/piece versions, expected item count, observed item count, run reference and sink receipt for each attempt. The Runs view exposes step inputs and outputs, but the downstream sink must supply the evidence of what was written. Leave all observed counts unfilled until execution. Completion of this written plan does not establish duplicate safety, approval enforcement or restart recovery.

The initial fixture needs no model call or social-network API, but a later deployment still has hosting, storage and operator costs. Replayed enrichment can add provider charges; count attempts as well as distinct sources. Set those limits and confirm edition features before connecting paid services. Choose Activepieces if maintaining service connections and review handoffs is the main need. If the main problem is selecting evidence for an answer, compare the separate Dify retrieval-revision trial with the same care about unexecuted checks.

Software repository and terms ↗