# Activepieces Limitations in 2026: What to Know
By Halvor Kristiansen · 2026-10-24 · Source: https://www.activepieces.com/blog/activepieces-limitations-in-2026-what-to-know
---
Where the MIT-licensed [Community](https://community.activepieces.com/t/10-000-github-stars-come-celebrate-with-us/6930) Edition, a cloud plan or the integration catalog stops short of what a buyer needs, that is an [Activepieces](https://www.activepieces.com/pricing) limitation. They're few, and they fall in the same places for most teams.
As of 24 October 2026, every claim below comes from [Activepieces](https://www.activepieces.com/pricing)' own pricing page, docs and changelog. Plan boundaries and catalog contents change, so treat them as a checklist to re-run before you commit, not a permanent record.
You can verify each of the three groups of limits before signing anything. Paid-plan boundaries come first: audit logs, SSO beyond the Team plan and embedding are handled through the sales form, not self-serve signup.
Self-hosting operations come second: the Community Edition runs on your infrastructure, so upgrades, backups and uptime become your team's job. Integration depth comes third: an app's presence in the catalog doesn't guarantee the specific action or trigger you need.
## Activepieces limitations are narrow, and they're knowable
### What counts as a limitation versus a preference
If the product can't meet a requirement in the edition or plan you intend to use, and you can show that against documentation, it's a limitation. "Needs SSO beyond Team, and that sits behind sales" is one.
Complaints about style, such as editor layout, are preferences, and this article leaves them out.
One further exclusion: security certification. **SOC 2 is in progress at Activepieces and isn't a held certificate.** If your procurement needs one today, that's a requirement to raise with the vendor, not something to assume.
## How automation platforms hit their limits in general
Every workflow tool is built from the same parts: a trigger that starts a run, steps that call other apps through connectors, and an engine that executes the steps and records what happened.
Limits appear where one of those parts meets a business constraint, such as who may sign in, where data may live, or whether a connector exposes the action you need.
Vendors resolve this in three broad ways. Hosted-only services such as Zapier and Make take operations off your hands and charge by usage, which suits teams without infrastructure staff. Self-hostable tools trade that convenience for control over data and cost.
Code-first approaches, from scheduled scripts to workflow engines like Temporal, remove connector limits but leave developers maintaining everything.
### How metering shapes cost
Usage-priced tools count tasks, operations or credits, so a flow that loops over a list or polls an API every few minutes can cost far more than one that fires once per event.
Self-hosted tools replace that meter with compute and the people who look after it.
### Connector depth matters more than breadth
A catalog count says little about whether the one action you need exists. Connectors differ in which triggers they offer, whether they poll or receive webhooks, and how they handle rate limits and expiring credentials.
Teams in a Microsoft estate often find Power Automate fits better, teams that want code steps inside a visual canvas look at n8n or Windmill, and teams that need durable long-running processes reach for Temporal.
## Where plan boundaries and licensing draw the line
Install and operate the MIT-licensed Community Edition yourself, and you are on one side of the line; the paid tiers are on the other. In the paid tiers the vendor hosts the product, and SSO beyond Team, audit logs and embedding go through sales.
To see the six tiers on the five dimensions that decide a rollout, read the table. "Not confirmed" marks a cell I couldn't verify, so check it on the [pricing page](https://www.activepieces.com/pricing) before you commit.
| Tier | Price per month | Credits | Users | Who operates it | Key features |
|---|---|---|---|---|---|
| Community Edition | No license fee; hosting is your cost | Not confirmed | Not confirmed | You | MIT-licensed core |
| Free | $0 | 1,000 | Not confirmed | Vendor cloud | Hosted builder |
| Plus | $20 | 10,000 | Not confirmed | Vendor cloud | Larger credit allowance |
| Team | Not confirmed | Not confirmed | Not confirmed | Not confirmed | SSO, scope not confirmed |
| Ultimate | Not confirmed | Not confirmed | Not confirmed | Not confirmed | Not confirmed |
| Embed | Not confirmed | Not confirmed | Not confirmed | Not confirmed | Embedding |
You can read, modify and redeploy the MIT-licensed core with no license fee. The constraint is operations: upgrades, backups and uptime become your responsibility, and the license gives you no support contract.
### What needs a paid plan
At $0, **Free gives you 1,000 credits**, which is enough to build and test a flow before any spend.
Plus is $20 with 10,000 credits, ten times that allowance, so it suits flows that run on a schedule. I didn't confirm how many credits a given run consumes, so measure one real flow before you size a plan.
Treat SSO, audit logs and embedding as an enterprise decision, in this order:
1. Write down the requirement: which identity provider, which audit retention, which embedding use.
2. Check whether Team covers the SSO need.
3. If it doesn't, or you need audit logs or embedding, send the requirement through the [sales form](https://www.activepieces.com/sales).
## What self-hosting Activepieces demands from your team
Before day one is over, you need a Docker host with room for four components, and after it a team that owns upgrades, backups, scaling and security; none of that is handled for you.
Alongside the app and the worker, the deployment needs a PostgreSQL database and a Redis instance, all running as containers. Per the [hardware documentation](https://github.com/activepieces/activepieces/blob/6b04e9e9/docs/install/configuration/hardware.mdx), the app needs 4 GB of RAM and the worker needs 4 GB, so those two alone claim 8 GB.
**10 GB is the floor across four components**, because PostgreSQL and Redis need 1 GB each. A request for a "small VM" will fail review, so size the host above that figure.
1. Provision a Docker host with at least that memory.
2. Provide PostgreSQL and Redis, on the same host or separately.
3. Start the containers and set their environment variables.
4. Log in and confirm a test flow runs.
After deployment, the first screen is the Agents dashboard, with a sidebar listing Flows, Tables, MCP, Todos and, under Misc, Enter Platform Admin and Connections. That admin entry marks where your administrators will work, so name an owner for it before go-live.
### Upgrades, backups and scaling are yours
Because you schedule upgrades, someone must read release notes and test before changing production. PostgreSQL holds your flow definitions, so an untested backup is a risk you carry.
Double the throughput and **the worker memory bill roughly doubles too**, since scaling is per component: each extra worker adds another 4 GB of RAM, so there's no cost advantage from scaling.
Patching the host, rotating secrets and restricting network access also fall to your team.
If your audit window requires a completed SOC 2 report, you can't cite one today: it's in progress, not certified, and you should record that as an open item.
Does moving behind your own firewall cost you the enterprise controls? In most products it does, because the self-hosted build is the cut-down one.
Here it doesn't: the air-gapped enterprise build carries **the same list as the managed cloud**, with single sign-on, SCIM provisioning, custom roles, audit logs, release management and secret managers all present in both, and the docs for each show it.
Regulated and public-sector organisations run that edition in production, and MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces too. Pricing for it is quoted through the sales form.
## The strongest case against choosing Activepieces
Expect three objections: the connector catalog is smaller than Zapier's or Make's, the platform is younger and changes faster, and self-hosting moves its cost into staff time. Each holds, and each can be tested before you commit.
Read the table below as a screening step: it compares the four tools on connector count, hosting and licence, using each vendor's own pages. Where a count is missing, you haven't verified that tool's coverage of your systems.
| Tool | Connectors | Hosting options | Licence |
|---|---|---|---|
| Activepieces | 744 (counted from the monorepo) | Cloud or self-hosted | MIT Community Edition, paid editions for added features |
| Zapier | Not retrieved | Vendor cloud only | Proprietary |
| Make | Not retrieved | Vendor cloud only | Proprietary |
| n8n | Not retrieved | Cloud or self-hosted | Source-available, fair-code |
Only two of the four can run on your own hardware, and only one of those is under a permissive open-source licence, meaning you're dependent on vendors or the cloud for most of these choices. The rest of this section takes the objections in turn.
**744 connectors is a large catalog**, but the older vendors have had longer to accumulate niche connectors, so a legacy or sector-specific system is more likely to be missing here. Before committing, do this:
1. List every system the first three workflows touch.
2. Check each against the connector list.
3. For any gap, confirm that a generic HTTP request step can reach the system's API, and that someone on your team can maintain it.
On the second objection, pin the version and read the release notes before every upgrade, because behaviour can change between releases.
### Hidden labour in self-hosting
The licence is free, but the operator isn't. You own upgrades, backups, monitoring, secrets handling and restore testing.
The licence is free, but the operator isn't.
Budget staff time explicitly, and prove a restore works on an isolated machine with no outside network before you rely on it.
## How objections rarely decide outcomes
Those objections rarely decide the outcome because each gap has a fixed route to closing it. The MIT licence lets you inspect the code and leave with it, so the same offline discipline applies to integrations as to restores.
### Gaps you can close yourself
3 community-built integrations: that is what the project's repository [lists](https://github.com/activepieces/activepieces). That means you shouldn't assume a contributor has already built your niche system. Plan to build it, and treat any community integration as a bonus.
Stop at the first step that works; the order below runs from cheapest to most expensive. It shows that most gaps end at step two or three and never reach a replacement.
1. Check the 744-integration catalogue for the system, and read the integration's actions before assuming it covers your case.
2. Try an HTTP or webhook step. If the system exposes a REST API, you can call it directly with no new code.
3. Write a custom integration in TypeScript. You own it, and it runs inside your own instance with no outside dependency.
4. Contribute the integration upstream, so you stop maintaining it alone after each release.
5. Only then consider another tool.
### When another tool is the better choice
When the required integration is absent and has no usable API, step five is correct. When a system offers only a desktop client, a file-drop protocol or a proprietary driver, HTTP and webhook steps have nothing to call.
A custom integration then costs more than the workflow is worth.
The claim fails on a specific test. If your must-have system is missing from the catalogue, has no API, and your team can't maintain TypeScript, the objection decides the outcome. Run that check before procurement starts, not after.
The same applies to scale of ownership. If nobody on your team will own a self-hosted instance, a hosted alternative with a vendor-run connector may fit better.
## How Activepieces handles its own limits in practice
Start free on cloud or self-host the MIT-licensed Community Edition, then build one flow against your riskiest integration and see where it breaks.
Run these steps in order.
1. Create a free account on cloud, or deploy the Community Edition on a machine you control if your requirement is self-hosting.
2. Add a trigger that matches how your real data arrives, such as a webhook or a schedule.
3. Add two integrations, which are Activepieces' prebuilt app integrations, for the systems you depend on most, so those critical systems now connect directly through this platform.
4. Add an HTTP request step for the one system you suspect the catalogue doesn't cover.
5. Run it with realistic data and record what failed.
### Custom integrations and HTTP fallbacks
When a service has no integration, the HTTP request step calls its API directly. You supply the endpoint, authentication and payload yourself, so coverage gaps cost build time rather than blocking the flow.
### What it doesn't do yet
Activepieces doesn't cover every app with a prebuilt integration, so expect some HTTP work. SSO beyond Team, audit logs and embedding sit behind paid arrangements.
Self-hosting means you operate upgrades, backups and uptime. SOC 2 certification isn't held; the programme is in progress, so don't rely on it in a procurement review.
To start building, [sign up free](https://cloud.activepieces.com/sign-up). To compare plans, see the [pricing page](https://www.activepieces.com/pricing). For self-hosted enterprise, SSO beyond Team, audit logs or embedding, use the [sales form](https://www.activepieces.com/sales).
## Frequently asked questions
Is Activepieces really free to self-host? Yes: the MIT-licensed Community Edition costs nothing to run on your own infrastructure.
The constraint is that you carry the operations (upgrades, backups, uptime), and features reserved for paid plans stay locked. For self-hosted enterprise needs, the [sales form](https://www.activepieces.com/sales) is the route.
Does Activepieces hold SOC 2 certification? No. The SOC 2 programme is in progress, so it's not a certification you can cite in a vendor questionnaire today.
If your procurement cycle requires a report, ask sales for the current status in writing and re-check the vendor's security page before signing.
Which plan do I need for SSO or audit logs? SSO is available up to the Team plan; anything beyond that, and audit logs, go through the [sales form](https://www.activepieces.com/sales).
Plan boundaries change, so read the [pricing page](https://www.activepieces.com/pricing) the day you decide, not the day you shortlist.
What should I test before committing a team? Run these in order, on a machine you control:
1. Write down your constraints first: network access, data residency, and the compliance evidence your auditors will ask for.
2. Build your three most important flows, not a demo flow.
3. Confirm every integration you need exists and covers the actions you call, not just the app name.
4. Run a long, heavy flow and check what happens at the platform's run limits.
5. Check how long execution history is kept against your audit window.
6. Self-host a copy, then practise an upgrade and a restore.
7. Confirm SSO, audit logs and embedding against the pricing page before you commit.
When the list passes, [start free](https://cloud.activepieces.com/sign-up) and build the first flow.
## References
- [Activepieces](https://github.com/activepieces/activepieces/blob/6b04e9e9/docs/install/configuration/hardware.mdx)
- [Activepieces](https://github.com/activepieces/activepieces)