AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents
Activepieces replaces closed SaaS automation tools like Zapier with a self-hosted platform where every integration ("piece") is an open-source TypeScript package. Teams get the same visual workflow builder without sending data through a third party, and the pieces double as MCP servers for LLM tools like Claude Desktop and Cursor.
What This Does
This is a fork of activepieces/activepieces (23,993 stars upstream) containing roughly 24,000 files across five self-contained projects under packages/, tools/, deploy/, .agents/, and benchmark/. The core is a TypeScript monorepo (11,573 .ts files) implementing a visual automation builder, a type-safe piece framework, and an execution engine. The .agents/ directory holds MCP server definitions and skills for building pieces, auditing logs, and triaging security advisories.
How It Is Wired
Entry points sit in packages/core/execution/src/index.ts and packages/cli/src/index.ts. The execution engine routes runs through packages/core/execution/src/lib/engine/index.ts, which handles loops, branches, and retries. Agent orchestration lives in packages/core/execution/src/lib/agents/index.ts. The deploy/pulumi/index.ts handles infrastructure-as-code deployment.
The wiring is a monorepo with a central package registry—each piece is an npm package with its own package.json under packages/pieces/community/. The hub is the execution engine, which loads these packages at runtime. The widest blast radius is the engine's run loop: every workflow passes through it, so a change there affects all 200+ pieces. The graph shows no obvious cycles, but the sheer size (23,602 files in packages/) makes cross-package refactors slow.
How To Use It
Setup: Clone and install using npm (lockfile present):
git clone https://github.com/moses-y/activepieces
cd activepieces
npm install
Configuration: Copy .env.example to .env.dev and set AP_WORKER_TOKEN and other credentials. The committed .env.dev currently holds generated values—rotate them before use.
Running it: Start the server via the standard Activepieces command:
npm run start
The README documents deployment options via Docker (Dockerfile present) and Pulumi (deploy/pulumi/index.ts).
Real-World Use
A support team builds a workflow: a Slack trigger fires on a new message, the AI agent piece classifies intent, and a human-approval piece pauses execution before sending a response. The same piece becomes an MCP server for a Cursor session, letting the LLM call it directly. This is the core value—one piece definition serves both the visual builder and MCP clients.
Code Health & Issues
Static analysis found 11 issues (1 critical, 3 high):
Critical — Committed credentials in .env.dev with AP_WORKER_TOKEN holding generated values. Rotate and untrack.
High — .env.dev is tracked despite .gitignore excluding it; the ignore rule is correct, so this is an accident.
High — Third-party GitHub Actions unpinned (oven-sh/setup-bun@v2, docker/login-action@v4). Pin to commit SHAs.
High — Committed .env files in packages/server/api/.env.tests and packages/tests-e2e/.env.e2e.
Medium — No least-privilege permissions on GITHUB_TOKEN in CI, no Dependabot, mutable Docker base image, no dependency vulnerability scan, no pre-commit secret gate, and a 13.5MB GIF in docs/resources/.
Tests exist (635 files) and CI runs via GitHub Actions.
The Bottom Line
The core platform is solid and well-tested, with the MCP-server-as-piece design being genuinely useful. The committed credentials are a real risk that needs immediate rotation. Teams wanting a self-hosted, extensible automation platform with AI agent support should use this—but fix the secret hygiene first.
What the analyser found
Deployment readiness
6/7
✓Container image
✓CI pipeline
✓Lockfile committed
✓Test suite
✓README
✓License
✗No committed secrets
Composition
24,341 files
TypeScript11573
JSON10188
Markdown870
TSX767
YAML67
Shell24
ReactExpressDockerKubernetesTransformersVector store
Findings
LowSecret-shaped paths present; the code-health audit confirms or clears them .env.dev, packages/pieces/community/hashi-corp-vault/src/lib/actions/list-secrets.ts
Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.
critical1
high3
medium6
low1
Rotate the credentials in the committed environment filecritical
.env.dev
AP_WORKER_TOKEN hold generated values
These values are loaded by the application at boot, so a generated value here is a working credential for something that runs.
Fix: Rotate each named credential, remove the file from the index, and replace it with a keys-only example.
Untrack the file your own .gitignore says to ignorehigh
.env.dev
tracked although .gitignore excludes it
The author already decided this file must never be committed, so its presence is an accident nobody noticed, which means the credentials in it are the ones actually in use.
Fix: git rm --cached the path and rotate; the ignore rule is already correct.
Pin third-party GitHub Actions to a commit SHAhigh4 occurrences
A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.
Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.
Remove the committed .env and rotate what it holdshigh3 occurrences
A tracked .env is the most common route for a working key to reach a public clone, and it is the file the app actually loads, so the value is usually live.
Fix: git rm --cached the file, add it to .gitignore, rotate every credential it names, commit a .env.example with empty values.
Declare least-privilege permissions for GITHUB_TOKENmedium
.github/workflows/continuous-delivery-release.yml
1 workflow(s) declare no permissions, 1 of them reference secrets
With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.
Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.
Enable Dependabot or Renovatemedium
770 manifest(s), no update bot configured
Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.
Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.
An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.
Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.
Gate pull requests on a dependency vulnerability scanmedium
.github/workflows
no dependency scan in CI
This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.
Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.
Add a pre-commit secret gatemedium
a secret-shaped file is tracked and no repo-level gate is visible
Without a gate the same class of leak recurs on the next commit, so a leak finding is the symptom and this is the cause.
Fix: Add a pre-commit hook scanning staged content, and enable push protection.
Move large binaries to Git LFS or out of the repositorymedium
docs/resources/scale-pieces-cli.gif
1 blobs over 5MB: scale-pieces-cli.gif 13.5MB
One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.
Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.
Set timeout-minutes on the workflow jobslow2 occurrences
.github/workflows/ci.yml
2 workflow(s) declare no job timeout
A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.
Fix: Add timeout-minutes with a realistic bound to each job.
Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.