A lot of us self-host Activepieces on a VPS and it’s great — until the box reboots, the Postgres volume fills up, or you realize there are zero backups of the database holding every connection credential and flow you’ve built over the past year. The self-hosting we love is the control; the part we don’t love is being the database admin, the patch manager, and the on-call.
Here’s a middle path: run Activepieces on Google Cloud Run, where the boring-but-critical parts are managed for you, and it still scales to zero so the bill stays small. Let’s explore the value proposition in a bit more detail.
What you actually get vs. a VPS
The database is managed. We use Cloud SQL for PostgreSQL — automated daily backups, point-in-time recovery, no public IP, optional high-availability failover. No more “I hope that volume is fine.” This is genuinely the part that saves you at 2 a.m.
Scale-to-zero = actually cheap when idle. Cloud Run shuts instances down between webhook triggers; you’re billed for actual work, not 24/7 uptime. For a personal or small-team automation instance that’s mostly idle, this is often cheaper than a VPS running all day — you pay for compute seconds, not for the number of times your flows run. That difference matters a lot once you’re running hundreds of flows daily.
Secrets are handled properly. The encryption key, JWT secret, and DB password are generated and stored in Secret Manager, not sitting in a .env file on disk. If someone gets a shell on the runner, they still don’t get your secrets. This matters more than it sounds for Activepieces specifically — the app accumulates API credentials for every service you connect: Slack, Stripe, your database, whatever. Those credentials deserve actual secrets management, not a file on a server.
A real Redis queue (Memorystore) is one toggle away if you outgrow the single-instance memory queue. Nice to know it’s there before you need it.
HTTPS and a public URL come built in. Webhooks just work — no reverse proxy or cert renewal to babysit.
IAP on the builder UI. Activepieces holds credentials for every service you’ve connected. Putting Identity-Aware Proxy in front of the UI means only your Google accounts can reach it — no VPN to maintain, no auth plugin to configure. It’s the kind of zero-trust control you’d normally have to architect separately; here it’s a toggle.
Binary Authorization for plugin supply chain. Binary Authorization ensures only images built and signed by your own pipeline can be deployed. A compromised upstream container cannot run, even if it makes it into a public registry. Not essential for a personal instance, but it’s a real supply-chain control and it’s available.
For the compliance-minded: VPC Service Controls (data exfiltration prevention) and customer-managed encryption keys (CMEK) are also available if you’re running Activepieces for a business with audit requirements.
The trade-offs, honestly
It’s Google Cloud, so you’re on a hyperscaler rather than a $5 VPS. That said, we have created an automated deployment module that is highly cost optimised. Google Cloud costs are usage-based; an idle instance is cheap, a busy one scales and bills accordingly.
Cold starts add latency to the first webhook after idle. If you’re receiving webhooks from external systems — payment processors, CRMs, anything where a missed event is a real problem — set min_instance_count = 1 to keep one instance warm. A missed webhook because the instance was cold is an event you can’t recover. For non-webhook use, zero is fine and costs you nothing at idle.
You’re trading some “it’s all on my box” purity for managed reliability. Whether that’s worth it depends on how much you value having backups and not being the DBA.
A note on reliability — especially for webhooks
If Activepieces is receiving webhooks that drive real processes (payments, tickets, CRM updates), you want those to stay up. On a VPS, your uptime is whatever your server uptime is. On Cloud Run with a warm instance, you can realistically target 99.9% availability — 43 minutes of error budget per month — and Cloud Monitoring can alert you when you’re spending that budget faster than expected with burn-rate alerting (fast burn triggers a page at ~14× normal error rate; slow burn catches gradual degradation at ~6×).
That’s the SRE way of thinking about it: instead of “is it up?”, you get “how fast am I spending my reliability budget?” It’s a more honest model, and the tooling to implement it is all there natively.
Flows as code — lightweight audit trail for free
Activepieces lets you export flows as JSON. Committing those exports to a git repo gives you a version history of every flow change — what changed, when, and why (if you write a commit message). It’s a lightweight audit trail you basically get for free. Rolling back a broken flow becomes “re-import the previous version” instead of trying to remember what you changed.
If you push further and run those flows through a proper CI/CD pipeline, you get the full engineering payoff: pull-request review before flows run in production, automated deployment across environments, one-command rollback. That’s the automation-as-code model — the same discipline you’d apply to application code. Measurable outcomes: fewer broken flows reaching production, faster recovery when something does break. DORA metrics folks would call this an improvement in change failure rate and MTTR.
What “one click” actually means here
The catch with doing all this by hand is that wiring Cloud Run to private Cloud SQL, Secret Manager, the Redis queue, IAP, Binary Authorization, and the right IAM permissions is a real afternoon-plus of Google Cloud fiddling — and you have to get it right, because Activepieces is holding your credentials. The RAD platform packages the whole thing as a single deployment — the platform engineering approach of encoding all the right wiring once so you don’t have to. The full config is documented in the Activepieces on Cloud Run guide. The platform is at radmodules.dev. I developed this as part of my engagement with the Google Cloud partner team, during which I developed and delivered numerous training programs on Infrastructure and Application modernisation on the Google Cloud platform.
I am posting because I believe “self-host but let the managed tier handle the database, backups, and secrets” is the right balance for many, and the RAD automation modules make this easier explore and adopt. Happy to answer questions on how RAD Modules can accelerate your adoption of Activepieces.