Activepieces Kubernetes Deployment: Setup, Sizing & Cost

Activepieces can run on any Kubernetes cluster, but it demands DevOps expertise and ongoing operational overhead. You will need a cluster (managed or self-hosted), PostgreSQL, Redis, and S3 storage. For most small teams, self-hosted Kubernetes costs more in labor than managed hosting. This guide walks you through deployment, sizing, the cost reality, and when to use managed hosting instead.

What is Activepieces?

Activepieces is an open-source workflow automation platform. It does what Zapier or Make do--connect your apps, automate repetitive work, run complex multi-step flows--but you host it yourself. The project has 24.8K GitHub stars and 100,000+ active installations. It supports 280+ integrations (Slack, Stripe, HubSpot, Google Sheets, Salesforce) and 400+ MCP servers for AI agent automation.

Self-hosting gives you full control: no vendor lock-in, no SaaS pricing per seat, and the ability to customize the platform. But it also means you own the infrastructure. If you already run applications on Kubernetes, deploying Activepieces there makes sense. If not, you are adding operational complexity.

Most teams start with Activepieces on Docker Compose or a managed platform. Opsily's managed Activepieces hosting handles infrastructure, upgrades, backups, and support for you.

Kubernetes Architecture for Activepieces

Activepieces on Kubernetes runs as a stateless application. Two main components: the API server (handles user requests, flow definitions) and worker processes (execute the actual flows). This design lets you scale horizontally: add more workers to handle more concurrent flows.

Here is the counter-intuitive part: workers are sized by concurrent flows, not total flow count. If you have 100 flows in your system but only 10 run at the same time, you need fewer workers than a system with 20 total flows running all 20 concurrently. This changes how you think about capacity planning.

Your cluster also needs PostgreSQL (stores flow definitions, user data, execution history) and Redis (job queue, caching). For production, Activepieces requires S3-compatible storage for file uploads and artifact storage. If you skip S3 and store files locally on pods, they vanish when the pod is replaced. Local storage defeats the purpose of Kubernetes.

Prerequisites: Cluster Setup, Tools & Skills

You need a Kubernetes cluster (AWS EKS, Google GKE, DigitalOcean DOKS, Hetzner Kubernetes Engine, or self-hosted). You need kubectl installed and working. Helm is optional but recommended--it simplifies deployments and upgrades.

You also need Kubernetes knowledge: Deployments, StatefulSets, Services, ConfigMaps, Secrets, persistent volumes. If your team has deployed other applications on Kubernetes, you are good. If not, expect a 1-2 week ramp-up time, plus ongoing on-call duty.

PostgreSQL 12+ and Redis 6+ are required. You have two choices: run them inside your Kubernetes cluster using Helm charts or persistent volumes, or use managed services (AWS RDS for PostgreSQL, AWS ElastiCache or Upstash for Redis). For production, managed services are simpler: automatic backups, scaling, failover, and you do not own the operational burden.

S3-compatible storage is non-negotiable for production. AWS S3, DigitalOcean Spaces, MinIO, Backblaze B2, or other S3-compatible services all work. Budget for this--you will have file uploads and artifact storage that adds up over time.

Step-by-Step Kubernetes Deployment

Activepieces publishes official YAML manifests and a community Helm chart. The official community Kubernetes tutorial (https://community.activepieces.com/t/kubernetes-deploylement/9068) provides working examples. It is 514 words, code-heavy, and assumes you understand Kubernetes well enough to troubleshoot.

Here is how deployment breaks down:

1. Create a namespace and secrets (database credentials, API tokens, S3 credentials).
2. Deploy PostgreSQL (or connect to a managed instance).
3. Run database migrations as a Kubernetes Job before starting the API.
4. Deploy the API Deployment and expose it via a Service.
5. Deploy worker Deployments (start with 1 worker, scale based on concurrent flows).
6. Configure Activepieces ConfigMaps (S3 bucket, database connection, worker concurrency).

The most common failures: (1) database initialization--migrations fail if the database is not ready, so use init containers or Jobs to sequence startup; (2) S3 misconfiguration--missing bucket, bad credentials, or wrong region; (3) service discovery--API and worker pods must resolve each other's DNS names, which requires proper Service definitions.

Test in a dev cluster first. Deploy a test flow end-to-end and verify file storage works.

Sizing Your Cluster: From Dev to Production

Activepieces sizing formula: 1 worker pod = 10-20 concurrent flows. 1 API pod = up to 50-100 concurrent flows (depends on request rate). Minimum CPU: 250m for API, 1 vCPU per worker. Minimum RAM: 512MB per pod.

A sample sizing table:

These are minimums. Add 20% headroom for spikes and pod eviction. PostgreSQL and Redis also consume resources. A PostgreSQL instance handling 50 concurrent flows needs 2 vCPU and 4GB RAM minimum. Redis is lighter: 512MB-1GB is usually enough for job queues.

Use Kubernetes Horizontal Pod Autoscaling (HPA) to scale workers automatically based on CPU utilization or custom metrics (e.g., queue depth). This saves money on dev/staging clusters and ensures production does not get starved.

Cost Breakdown: What Self-Hosted Kubernetes Actually Costs

Here is the hard reality. A small production Activepieces setup (50 concurrent flows) costs:

Infrastructure:

• 3-5 worker nodes (2 vCPU each) at EUR 3-30/month per node depending on your cloud provider: EUR 20-150/month
• 1 API pod (minimal overhead, shares cluster nodes): included above
• Managed PostgreSQL (db.t3.small on AWS RDS): EUR 30/month
• Managed Redis (AWS ElastiCache or Upstash): EUR 20-50/month
• S3 storage and egress: EUR 10-50/month depending on file volume
• Ingress/load balancer: EUR 0-30/month depending on your cloud
• Total infrastructure: EUR 100-300/month

DevOps labor:

• Initial setup: 40-80 hours (one engineer, full-time for 1-2 weeks)
• Ongoing maintenance: 10-20 hours per month (monitoring, backups, security patches, upgrades, troubleshooting)
• On-call support: salary cost (EUR 50K-80K/year for a junior DevOps engineer, or 2-3 days/week of senior eng time)
• Monthly labor cost: EUR 500-2000/month depending on team size and salary

Total TCO for self-hosted K8s: EUR 600-2300/month

For comparison, managed Activepieces hosting on Opsily typically costs EUR 50-200/month depending on scale. No DevOps labor. No on-call duty. Automatic backups and upgrades.

The break-even point for self-hosted K8s: 500+ concurrent flows or 100+ new flows per day. Below that, managed hosting is cheaper on total cost of ownership.

Common Kubernetes Pitfalls & Troubleshooting

WebSocket connectivity: Activepieces uses WebSockets for real-time flow execution updates. If your ingress controller (nginx-ingress, Istio, AWS ALB) does not support WebSockets, flows timeout with "connection refused" errors. Fix: enable WebSocket support in ingress annotations or upgrade to a WebSocket-capable gateway.

S3 storage misconfiguration: The most common self-hosted failure. If S3 is not configured, Activepieces stores files locally on pod disk. When the pod is replaced (during an upgrade or node failure), the files vanish. Always configure S3: set bucket name, region, credentials, and enable signed URLs in Activepieces config. Test it: upload a file through the UI, kill the pod, verify the file still exists after the pod restarts.

Database connection pooling: PostgreSQL has a default connection limit (100). Under load, Activepieces API and worker pods exhaust the pool, causing "too many connections" errors. Fix: increase max_connections in PostgreSQL (managed services let you do this), or deploy PgBouncer as a connection pooler in front of PostgreSQL.

Secrets management: Kubernetes Secrets are stored unencrypted in etcd by default. For production, use a secrets vault: HashiCorp Vault, AWS Secrets Manager, or sealed-secrets. This matters for database passwords and API tokens.

Upgrades: Activepieces updates are frequent and sometimes require database schema migrations. Always test in staging. Workers are stateless, so rolling updates are safe. Sequence: run a database migration Job, then redeploy API pods, then workers. Monitor logs for errors before rolling back.

Self-Hosted vs. Managed Hosting: TCO Reality Check

Self-hosted Kubernetes trades simplicity for control. You get full ownership of infrastructure, no vendor lock-in, and cost predictability at scale (500+ flows). But you pay in labor, on-call stress, and upfront setup time.

Managed hosting is the opposite. You pay a monthly fee; the provider handles infrastructure, updates, backups, and support. Faster to market (hours, not weeks to launch). Lower operational risk. Predictable monthly cost.

The business case: If your team already runs Kubernetes, has on-call DevOps coverage, and has 500+ concurrent flows, self-hosted makes sense. If you are a startup or small team (under 50 people), or if you need to launch fast, managed hosting is almost always cheaper when you account for labor. Compare costs and requirements in our managed Activepieces hosting guide.

Frequently Asked Questions

Do I need Kubernetes to run Activepieces?

No. Activepieces works on Docker Compose, single servers, Platform-as-a-Service (Northflank, Railway, Render), and more. Kubernetes is best if you already have a cluster and want a standardized deployment. See our Docker deployment guide for alternatives.

What database does Activepieces require?

PostgreSQL 12 or later. Activepieces stores flow definitions, execution history, and user data in PostgreSQL. For production, use a managed service (AWS RDS, DigitalOcean, Render) to simplify backups and reduce operational overhead. Do not run PostgreSQL as a Kubernetes pod unless you have persistent volume and backup expertise.

Can I run Activepieces on a small cluster?

Yes. A cluster with 2 vCPU and 2GB RAM handles about 10 concurrent flows. Minimum: 1 API pod (512MB RAM, 250m CPU) and 1 worker (512MB RAM, 1 vCPU). Add more workers to increase concurrency. Memory fills faster than CPU under load; monitor carefully.

How do I back up Activepieces on Kubernetes?

All data lives in PostgreSQL and S3. Automate PostgreSQL backups (managed services do this by default). Enable versioning on your S3 bucket and set a retention policy. Store backups in a separate AWS account or region. Test restores quarterly; a backup without a tested restore procedure is useless.

Can I upgrade Activepieces without downtime?

Yes. Activepieces is stateless, so rolling updates work. Sequence: run database migrations as a Job, redeploy API pods, then worker pods. Monitor logs for migration errors. Test upgrades in staging first.

Is Activepieces secure for production?

Yes, if you follow best practices. Use a secrets vault for credentials, enable S3 signed URLs, restrict network access with Kubernetes NetworkPolicies, and use HTTPS only. Never expose the API to the internet without authentication; always use a private network or auth proxy.

The Bottom Line

Self-hosted Kubernetes gives you control but demands DevOps expertise and ongoing labor. For small teams, managed hosting is almost always cheaper and faster to market.

The decision: If your team already runs Kubernetes, has on-call DevOps, and expects 500+ concurrent flows, self-hosted makes sense. Otherwise, managed hosting saves time and money. Compare your options in our managed Activepieces hosting guide.