Activepieces is easy to run in a few minutes. That is exactly why people keep putting the hobbyist container in places where it does not belong.

The project gives you two sensible starting points. A single Docker container uses embedded PGLite and an in-memory queue. A Docker Compose deployment splits the app, worker, PostgreSQL, and Redis into four containers. Both are free to start. They are not the same operational choice.

Activepieces production architecture with app, workers, Redis, PostgreSQL, and object storage

If your goal is a private MCP gateway for a few personal automations, the small install is a good deal. If you are about to connect a public webhook, hand an agent write access to a CRM, or let several people depend on it, the shortcut becomes the risk. Here is the boundary I would use.

The cheapest safe install

For a laptop or a disposable VPS, start with the official hobbyist image. It needs Docker and nothing else. Activepieces stores its data under ~/.activepieces, listens on port 8080, and makes the first account you create the administrator. There is no default password waiting to be guessed.

docker run -d --name activepieces -p 8080:80 \
  -v ~/.activepieces:/root/.activepieces \
  -e AP_DB_TYPE=PGLITE \
  -e AP_REDIS_TYPE=MEMORY \
  -e AP_FRONTEND_URL="http://localhost:8080" \
  activepieces/activepieces:latest

Open http://localhost:8080 and create the admin account. Before building anything important, make the volume backup explicit:

cp -r ~/.activepieces ~/.activepieces-backup

That copy is boring, but it separates a recoverable test from a lost workflow. The official docs say the embedded setup cannot scale to multiple instances and cannot be upgraded to Enterprise. It is a single-machine setup by design.

For local experiments, that is fine. For a remote server, change AP_FRONTEND_URL to the real HTTPS address before you expose webhooks. A tunnel such as ngrok http 8080 is useful for testing, but the documentation is right to call it unsuitable for production. A public webhook is an internet-facing application, even if the flow behind it only sends a Slack message.

The useful trick is to keep the MCP surface narrow. Activepieces says its MCP server can expose the platform alongside 760+ other apps through one connection. Enable it under Settings, then MCP Server, and connect your client using the server URL. The first connection uses OAuth. Credentials are stored with limited scopes, and the MCP page says they are protected by 256-bit encryption.

Do not treat that as permission to connect an agent to every action in your workspace. Start with read-only tools. Add one write action only after you have tested the exact input it receives. A workflow that can look up a customer is a different security problem from one that can update a customer, even if both appear in the same assistant menu.

The hosted comparison is also more subtle than "self-hosting is free." Activepieces lists Community Edition as free forever, with no cap on runs, users, or flows, but it also says the free self-hosted edition leaves out the team and admin layer, including SSO, roles, audit logs, secret managers, Git Sync, and some agent features. Your VPS bill may be zero. Your time spent checking upgrades and restoring backups is not.

When to move beyond the one-container setup

Move to Docker Compose when any of these becomes true: the webhook is business-critical, more than one person depends on the flows, you need a queue that survives a restart, or you want a realistic path to multiple workers.

The official Compose install requires Docker Compose v2, at least 2 vCPUs, and 4 GB of RAM. It creates four roles: the app serves the UI and API on port 8080, workers run flows, PostgreSQL stores flows and connections, and Redis handles the job queue. That division is more work than one container, but it gives failures somewhere to go besides your only process.

The fastest official path is:

curl -fsSL https://get.activepieces.com | sh

The installer generates the configuration and secrets. Check that AP_ENCRYPTION_KEY, AP_JWT_SECRET, and AP_POSTGRES_PASSWORD are non-empty. Back up the generated .env file. Without the encryption key, a database dump may contain your data while still being unable to decrypt the stored connections.

Then verify the stack before you build a flow:

docker compose -p activepieces ps
curl http://localhost:8080/api/v1/health

You want all four containers up and at least one worker visible under Platform Admin, Infrastructure, Workers. The common failure is not an exotic database bug. The worker points AP_FRONTEND_URL at localhost, which means the worker container tries to find itself instead of the app. Inside the Compose network, the worker needs to reach http://app; the browser-facing app still needs the public HTTPS URL.

There is another trap in the official setup. The PostgreSQL data lives in the postgres_data Docker volume, not in the activepieces project folder. Backing up the folder alone does not back up your flows. Before an upgrade, dump the database and keep the environment file together with the dump:

docker compose -p activepieces exec postgres pg_dump -U postgres activepieces > backup.sql
cp .env .env.backup

Review breaking changes, then upgrade. Do not blindly track latest on a production instance just because the first install used it. The Compose docs keep the image version in AP_VERSION, which gives you a simple rollback point.

The production sizing guidance gets even less friendly to tiny VPS fantasies. Activepieces recommends one worker per concurrent flow, with each worker at 0.5 vCPU and 1 GB RAM at concurrency 1. It lists an app at 1 vCPU and 1 GB, managed PostgreSQL at 2 vCPUs and 4 GB, Redis at 1 vCPU and 1 GB, and S3-compatible object storage for files. That is not a $5 toy deployment once you need the full production shape.

This is where self-hosting stops being a pricing hack and becomes infrastructure. The managed Free plan is $0, Plus is listed at $16 per month when billed yearly, and Team at $166. Cloud also charges credits for runs and AI actions. Self-hosting removes the platform subscription and run cap, but it does not remove model API costs, storage, TLS, monitoring, or the person who notices when a worker has stopped processing jobs.

The decision is straightforward. Use the one-container install for a personal MCP sandbox, local experiments, or a workflow you can recreate. Use Compose when data must survive container replacement, webhooks matter, or you need a worker boundary. Pay for managed hosting when you need team controls or support and those services cost less than your maintenance time.

For a broader cost comparison, read the n8n self-hosting break-even math. The same lesson applies here: the server is only the visible part of the bill.

The best Activepieces deployment is not the one with the lowest monthly invoice. It is the smallest one whose failure would not surprise you.

Sources