When is Activepieces Community Edition enough, and when do you need a paid plan?
Activepieces Community Edition is enough when one automation core covers the whole requirement and no policy obliges you to centralize sign-in or keep an audit trail of changes. The Community Edition is MIT licensed, and the workflow engine, the editor and the pieces (integrations) sit inside it. A team that self-hosts it with Docker Compose, PostgreSQL and Redis, or with the Helm chart on Kubernetes, runs the automation core in its own infrastructure without a subscription. This fits a platform team automating internal tasks for a small group of builders who sign in with local accounts and keep change records in existing ticketing or source control. Before you commit, confirm with your security team that local accounts and manually managed flows meet your access and change-control standards, because the pricing page places those controls in paid tiers.
Move to a paid plan when a written control asks for something the Community Edition does not list. SSO is the first gate: the pricing page starts it at the Team plan, listed at 200 US dollars a month for up to 25 users. If your policy requires every builder to authenticate through your identity provider, Team is the lowest tier that covers it on the published pricing. Audit logs, Git sync and releases, SCIM and external secret managers appear only in the Ultimate plan. Audit logs answer the auditor's question of who changed a flow and when. Git sync helps when flows must pass code review before production. SCIM matters when joiners and leavers must be removed from the platform automatically, and external secret managers matter when credentials cannot live in the platform database. Each condition is a separate decision, so list them one by one before you buy a tier for a single feature.
Which Activepieces features sit in Community and which need a paid plan?
This table sorts the Activepieces pricing page split between the self-hosted Community Edition and the paid Team and Ultimate plans, covering SSO, audit logs, Git sync and releases, SCIM, external secret managers, on-premises deployment and embedding. Read each row as a question to confirm: the Community Edition is the automation core on its own, SSO starts at Team, and the governance features are listed only for Ultimate. Free allows 1,000 credits a month for up to 5 users, and Plus costs 20 US dollars a month, so check Plus credit and user limits on the pricing page before purchase.
| Feature | Community Edition | Team | Ultimate |
|---|---|---|---|
| Automation core (flows and pieces) | Self-hosted core under the MIT license, run in your own infrastructure | 25 users at 200 US dollars a month | Custom pricing, quoted by Activepieces |
| Single sign-on (SSO) | Not listed on the pricing page for Community | Where SSO starts | Available, since SSO starts at Team |
| Audit logs | Not listed on the pricing page for Community | Not listed for Team, confirm before purchase | Listed for Ultimate only |
| Git sync and releases | Not listed on the pricing page for Community | Not listed for Team, confirm before purchase | Listed for Ultimate only |
| SCIM provisioning | Not listed on the pricing page for Community | Not listed for Team, confirm before purchase | Listed for Ultimate only |
| External secret managers | Not listed on the pricing page for Community | Not listed for Team, confirm before purchase | Listed for Ultimate only |
| On-premises deployment | Self-hosted with Docker Compose or the Helm chart, operated by you | Confirm on the pricing page | Can run in the cloud or on premises |
| Embedding (white-label builder and SDK) | Not listed on the pricing page for Community | Confirm on the pricing page | Pricing page lists embedding from 36,000 US dollars a year |
What licensing and support terms change between editions?
The code licenses and the vendor's support commitments are separate questions, and they change at different points between the Community Edition and the paid plans. Each card below covers one term you should pin down before comparing prices. Confirm every point in writing for the specific plan and version you intend to run.
Community Edition license
The Activepieces community edition is MIT licensed, which generally permits you to use, modify and redistribute the code, subject to the license notice. That covers the automation core you would self-host in your own infrastructure. Check the license file in the exact release you deploy, and have legal confirm that your planned internal or customer-facing use fits the MIT terms.
Commercial license on enterprise code
Code under packages/ee is covered by a commercial license rather than MIT, so it is not part of the open-source grant. Features that live in that directory, such as the enterprise capabilities gated by plan, are governed by the vendor's commercial terms. Ask the vendor which features map to packages/ee and what rights a paid subscription grants for running, modifying or redistributing them.
No contracted SLA on the free edition
The self-hosted Community Edition carries no vendor-contracted service level agreement. Community support, documentation and third-party hosting templates are not a commitment from the vendor on response times or fixes. If uptime or incident response matters to your business, treat that as a gap you must fill through a paid plan, a support contract or your own operating model.
Support scope on paid plans
Paid plans differ in the support they include, and the pricing page does not give the full terms for each tier. Ask for the written support scope for Plus, Team and Ultimate separately: channels, hours, severity definitions, response targets and whether self-hosted deployments are covered. Compare those answers with the features you need, since a plan that unlocks a feature may not include the support you expect for it.
Update cadence and patch windows
Release frequency is visible on the public release page, where recent versions were published within days of each other, but that does not guarantee backports, security patch timing or support for older lines. Ask the vendor how long each release line receives fixes, whether paid customers get patches on a faster schedule, and how you would learn about security advisories before a public release.
Redistribution and hosting rights
Your right to host Activepieces for other companies, embed it in a product, or run it on premises depends on the plan and the license under which each component ships. The embedding offer and the Ultimate on-premises option are separate commercial agreements. Before you offer Activepieces to customers or partners, get written confirmation of the redistribution, sublicensing and deployment rights that apply to your intended model.
Where SSO starts and why identity integration drives the upgrade
SSO starts at the Team plan on the Activepieces pricing page, which means the Community Edition does not include single sign-on as a listed feature. For a team whose policy requires every workflow user to sign in through the corporate identity provider, that is the decision point. Before comparing prices, confirm which login path your policy actually accepts. An IdP-backed login is one option, but a policy written as "all human access goes through the IdP" may be satisfied in other ways, depending on how your auditors and security team read it.
Run a short check before you decide. List every access path to the Activepieces console and to the workflow editor, then ask whether each one can be fronted by a control you already run, such as a reverse proxy or access gateway that enforces your IdP's multi-factor policy, network restrictions that limit the console to a management network, and a rule that accounts are created only by an administrator. These controls sit outside the application, so they do not replace per-user SSO inside Activepieces. They may still answer the policy question for a small, internal deployment. Record which controls you would rely on and where each one is documented, because that record is what an assessor will ask to see.
Confirm the following with Activepieces before you commit: whether the Community Edition offers any native login method that can be tied to your IdP, what the Team plan's SSO setup requires from your side (protocols, group mapping, and how existing local accounts are migrated), and whether the Team plan's user limit fits your headcount. If you need SCIM provisioning to remove leavers automatically, that sits in the Ultimate plan on the pricing page, so an identity gap usually shows up there first. Ask for the written terms in the quote, not only the pricing table, so that identity features are tied to a named edition.
Which governance features matter for which team?
Security and compliance leads usually need evidence before they need features. The governance questions are who changed a flow, who read a credential, and whether the platform can prove both after the fact. The pricing page places audit logs, SCIM and external secret managers in the Ultimate plan, while SSO starts at Team. That split means a team can run single sign-on on Team and still lack the audit trail and lifecycle controls an assessor may ask about.
- Audit logs: Worth paying for when an assessor or internal audit needs a record of administrative and flow changes that is not maintained by hand.
- SCIM provisioning: Worth paying for when joiners, movers and leavers are numerous enough that removing access by hand leaves gaps.
- External secret managers: Worth paying for when policy requires credentials to live in a vault you already operate, not in the platform database.
- SSO on Team: Useful on its own for sign-in consistency, but it does not replace deprovisioning or logging.
- Hosting footprint: Confirm whether Ultimate can run on premises if your evidence must stay inside your network.
Confirm with Activepieces exactly which audit events are logged, how long they are retained, whether they can be exported to your SIEM, and whether SCIM deprovisioning is tested in your identity provider.
Platform engineers care about change control. Flows that automate production tasks need review, promotion between environments and a rollback path. The pricing page lists Git sync and releases only for Ultimate, and the Community Edition does not include them. Without Git sync, teams usually fall back on exporting flows by hand or on careful manual change records, which works at small scale and becomes fragile as flow counts grow.
- Git sync and releases: Worth paying for when flows are changed by several people and need pull request review and tagged releases.
- Environment promotion: Worth paying for when development, staging and production must hold the same flow definitions with controlled differences.
- Community deployment: The Community Edition, deployed with Docker Compose or the Helm chart, can still run automations; the trade-off is manual change tracking.
- Operational ownership: Your team carries upgrades and backups on Community, so factor that effort into any comparison.
- Release cadence: Activepieces publishes frequent releases such as 0.92.3 on October 12, 2026, so a release process matters more than it would for slower products.
Confirm whether Git sync supports your branching model, what it exports and imports, and whether the Ultimate plan's on-premises option includes the same release mechanism.
Product teams that want automation inside their own application face a different question. The embedding offer, with a white-label builder and SDK, is priced from 36,000 US dollars a year on the pricing page. That figure is a list starting point for a vendor conversation, not a full cost. For a product team, the decision is whether building an in-product automation experience justifies a recurring license, or whether the Community Edition's API and pieces can be wrapped with your own interface at lower cost.
- Embedding license: Worth paying for when customers must see and configure automations inside your product under your brand.
- Internal automation only: The Community Edition or a Team plan is usually enough when automations run behind the scenes.
- Build cost: Custom interface work is a separate engineering cost that recurs with each product change.
- Support and upgrades: Embedded deployments need a plan for version upgrades that do not break customer-facing screens.
- Licensing scope: Confirm whether embedding rights cover your customers, your hosting model and any on-premises deployment.
Confirm the embedding terms in writing, including the SDK version policy, white-label limits, the number of tenants covered and what happens to embedded features if the subscription ends.
Which plan runs on premises and what that requires
The Ultimate plan is the only Activepieces option the pricing page describes as able to run in the cloud or on premises, and it is custom-priced, so the on-premises question is a commercial conversation rather than a download. The Community Edition is different in kind: it is the self-hosted automation core under the MIT license, and you run it on your own infrastructure by design, using the Docker Compose path with PostgreSQL and Redis or the Helm chart for Kubernetes. Teams that need no vendor-supplied deployment packaging can stay on Community and own the install, upgrades and hardening themselves. Teams that need a deployment the vendor packages and supports for their environment should ask about Ultimate before they commit to a build.
What the team gains on Ultimate is an agreed deployment scope and the enterprise controls listed for that plan, including audit logs, Git sync and releases, SCIM and external secret managers. What it gives up is the simplicity of owning the stack outright, and it takes on a commercial relationship that recurs. Ask the vendor, in writing, which deployment packaging ships with Ultimate, whether it is a container image, a Helm chart, or both, and which versions are covered. Confirm whether an air-gapped install is supported, how license keys and updates reach a network with no outbound access, and where the support boundary sits between vendor fixes, your own patches and any community-maintained templates.
Before deciding, check whether the enterprise code in the packages/ee directory is needed for your controls at all, since that code is under a commercial license and is separate from the MIT community core. If your environment cannot accept outbound connections, the air-gapped question drives the whole decision, so get a written answer on it first. A DeployOpen scope for hardening, backup and upgrades can be written against either path once the vendor's packaging and support terms are confirmed.
What does each Activepieces edition cost to run?
This table lists the cost components behind each Activepieces option, from published software prices to infrastructure, internal effort and optional DeployOpen scope. Read it as a map of who gets paid for what and which costs recur, then use the quote checklist to compare like with like.
| Cost component | Who is paid | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Community Edition software | No license fee; MIT licensed core (activepieces/activepieces repository) | Not applicable | Free to run, but you own upgrades, backups and hardening |
| Plus plan subscription | Activepieces, at 20 US dollars a month (Activepieces pricing page) | Recurring monthly | Confirm whether Plus is cloud-only or can be self-hosted before budgeting |
| Team plan subscription | Activepieces, at 200 US dollars a month for up to 25 users (Activepieces pricing page) | Recurring monthly | User count above 25, and whether SSO is needed (SSO starts at Team) |
| Ultimate and embedding quotes | Activepieces, custom priced for Ultimate; embedding starts at 36,000 US dollars a year (Activepieces pricing page) | Recurring, usually annual | Scope of on-premises deployment, audit, Git sync, SCIM and secret manager needs |
| Infrastructure for Docker Compose or Helm | Your cloud provider or data center vendor | Recurring | PostgreSQL and Redis sizing, number of workers, high availability and backup storage |
| Internal operations effort | Your platform, security and automation staff | Recurring, with a one-time setup | Upgrade cadence, on-call coverage, connector maintenance and access reviews |
| DeployOpen implementation scope (optional) | DeployOpen, under a fixed-scope written agreement | One-time, with optional recurring retainer | Number of integrations, identity and secrets wiring, hardening and documentation depth |
| Migration from another automation tool | Your staff or a partner | One-time | Number and complexity of existing workflows and connectors to rebuild |
How to move from Community Edition to a paid plan and back
This sequence gives you a documented, tested path onto or off a paid Activepieces plan, with flows, identity and secrets accounted for before any production change. It ends with a rollback you have rehearsed, so the move can be reversed if a feature you depended on is not available on the target plan.
Inventory flows, pieces and dependencies
Your automation owner lists every flow, its trigger, its connections and each piece it uses. The Activepieces repository lists more than 280 pieces, and about 60 percent of them are community contributed, so record which pieces come from the community catalog and check each one against the version you run. Include credentials, schedules, webhook URLs and any flow that calls out to an AI agent or MCP server. Done when you have a spreadsheet or export that maps every production flow to its pieces, owners and downstream systems.
Confirm the target plan against your requirements
Your platform lead and compliance owner compare the requirements list with the current Activepieces pricing page. Check which features each plan lists: SSO starts at the Team plan, while audit logs, Git sync and releases, SCIM and external secret managers are listed only for Ultimate, and the Ultimate plan is the one that can run on premises. Ask Activepieces in writing to confirm any feature that matters to your audit or access controls, and record the answer. Done when a signed decision note names the plan and the features it must include.
Map identity and secret migration
Your identity team documents how users sign in today and how they will sign in after the move, including any SSO provider, SCIM provisioning and where connection secrets are stored. If you move to a plan with external secret managers, plan how each credential is rotated into the new store and who holds access to it. If you move down, plan how users and secrets return to the Community Edition setup without leaving orphaned accounts or copies. Done when a migration table lists every user group, identity source and secret location with an owner and a cutover action.
Rehearse the move in a staging instance
Your platform engineer deploys a staging instance using the same Community Edition version as production, or the target edition if you are upgrading, and imports a representative subset of flows. The Activepieces installation overview recommends Docker Compose with PostgreSQL and Redis, or the Helm chart for Kubernetes, so match your production layout. Run each flow with test data and confirm the outputs match production behavior. Done when every critical flow passes a documented test run in staging and the team has noted any piece or setting that behaves differently.
Check audit and access commitments before moving down
Before any move from a paid plan to Community Edition, your compliance lead lists every control that depends on audit logs, SSO, SCIM or external secret managers. Moving down removes those paid features, so the controls must be replaced, accepted as a documented risk, or kept on the paid plan. Confirm with your auditor or assessor which evidence they expect after the change. Done when the compliance owner signs off on a gap list, and nothing in that list is unresolved for production.
Cut over production during a planned window
Your platform team schedules the change window with the flow owners and freezes edits to production flows. Export the current configuration and database backup, deploy or upgrade the target edition, reconnect identity and secrets, then re-enable triggers flow by flow. Watch run history for failed executions, webhook errors and duplicate runs. Done when every production flow shows successful runs against live triggers and the flow owners confirm their outputs.
Document and rehearse the rollback
Your platform engineer writes a rollback runbook covering the backup restore, the previous container or chart version, identity and secret reversion, and the order in which triggers are paused and resumed. Test the rollback in staging before the cutover, so the team knows how long each step takes on your infrastructure. Store the runbook with the migration record and the sign-off notes. Done when the rollback has been run successfully in staging and the runbook is approved by the platform and compliance owners.
What do buyers ask before choosing an Activepieces plan?
What does a paid Activepieces plan cost compared with self-hosting Community Edition?
The Community Edition is MIT licensed, so the software itself carries no license fee, but you pay for the infrastructure, the database and Redis, and the staff time to run it. The published pricing page lists Plus at 20 US dollars a month, Team at 200 US dollars a month for up to 25 users, and a custom-priced Ultimate plan, and embedding starts at 36,000 US dollars a year. Those figures come from the vendor page and change, so confirm current terms at Activepieces pricing before budgeting. Ask for the cost of each plan in writing, including user caps and credit allowances.
How long does a self-hosted Activepieces rollout take?
No duration is published for this work, so treat any timeline as something to agree in writing rather than assume. The main drivers are whether you deploy with the Docker Compose path that uses PostgreSQL and Redis or the Helm chart for Kubernetes, how many integrations (pieces) your flows need, whether you must connect identity and secrets systems, and how many approval steps your change process requires. A small pilot on one host usually moves faster than a multi-environment rollout with backups and monitoring.
What skills does the internal team need to run Community Edition?
Your team needs people who can operate PostgreSQL and Redis, manage container or Kubernetes deployments, handle TLS, backups and upgrades, and maintain the credentials that flows use. Someone must also own the workflows themselves, including testing changes and reviewing which connected accounts each flow can reach. If you plan to build custom pieces in TypeScript, add developer capacity for that. Confirm these requirements against the current installation documentation for your chosen deployment method.
Can we run Community Edition without outside help?
Yes, if your team has the infrastructure and automation skills listed above and accepts that it carries the upgrade, backup and security maintenance itself. The Community Edition is the automation core on its own, and the installation overview recommends Docker Compose with PostgreSQL and Redis. Organizations with thin platform staff often find the first upgrade and the first incident the hardest parts, so decide before launch who will respond to each.
Can DeployOpen implement Community Edition or a paid plan under a written scope?
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. That applies to Community Edition deployments. DeployOpen is not an official partner or reseller of Activepieces, and it does not sell or set Activepieces plan terms, so confirm licensing for any paid tier directly with the vendor. Ongoing support and upgrades are available as retainers, and DeployOpen does not publish a price list, so a quote follows from the written scope.
How are upgrades handled when moving from Community Edition to a paid plan?
Moving between editions is a licensing and configuration step as well as a deployment step, so ask the vendor how a plan change is activated on a self-hosted instance and whether it requires a new license key, a version match or a migration. Confirm which features (SSO, audit logs, Git sync, SCIM, external secret managers, on-premises Ultimate) need configuration changes and whether any data moves. Keep a tested backup of PostgreSQL and your configuration before any edition change, and check the current release notes, such as the Activepieces GitHub releases page, for version-specific steps.
Which features actually require a paid plan?
According to the pricing page, SSO starts at the Team plan, while audit logs, Git sync and releases, SCIM and external secret managers are listed only for Ultimate. The Community Edition covers the automation core on its own. If you need compliance evidence from audit logs or centralized identity provisioning, confirm with the vendor that the feature is available in your plan and deployment model before you commit, because feature availability is set by the published terms.
How DeployOpen scopes Activepieces implementations for either edition
DeployOpen scopes every Activepieces engagement in writing before work starts, and the edition decision shapes the scope more than any other input. A Community Edition deployment inside your own cloud account, data center or air-gapped network is scoped around the automation core, its PostgreSQL and Redis dependencies, the Docker Compose or Helm deployment path, backups, upgrades and the integrations your teams actually need. If your plan is Plus or Team, the scope adds the hosted-plan configuration and identity setup your contract covers. If you are evaluating Ultimate for audit logs, Git sync, SCIM or external secret managers, the scope has to name each of those features, the environment they run in and who signs off on them. Confirm the edition and its feature list with Activepieces before the statement of work is drafted, because a scope written against the wrong edition will be wrong on delivery.
DeployOpen works under fixed-scope agreements. The written scope defines the deliverables, the environments, the integrations in the first release and the handover items such as runbooks and documented configuration. Changes after signature go through a written change request, so the price and timeline move with the scope rather than drifting. DeployOpen does not publish a price list, and a quote follows from the written scope. To get a comparable quote, ask for each option separately: Community Edition deployment only, Community Edition with a named set of integrations, and any Ultimate or embedding work you are considering. Ask which costs are one-time and which recur, and what your own licensing with Activepieces covers.
Ongoing support, upgrades and continuous testing are available as retainers, which matter most when your team cannot absorb the upgrade cycle alone. Ask for the upgrade approach in writing: how each Activepieces release, such as the 0.92.x line shown in the project's GitHub releases, is tested against your integrations before it reaches production, and who approves the rollout. DeployOpen is not an official partner or certified provider of Activepieces, and it does not issue audit reports or certifications. If an audit or assessment depends on Activepieces controls, your independent assessor will evaluate the evidence, and the scope should specify which configuration evidence DeployOpen will prepare for them.
