Deploy Activepieces on Google Cloud Run with Production Guardrails Built In

Spinning up Activepieces with docker run takes minutes. Running it so you'd trust it with real business workflows — that's the part that could take weeks. Activepieces isn't just another stateless service: it holds API credentials, OAuth tokens,
webhook secrets, and integration keys for every system it touches — your CRM, your payment processor, your data warehouse. A poorly secured Activepieces instance is a skeleton key to your entire integration surface. "Production" for this app means a backed-up database, managed secrets, supply-chain controls on plugins, a zero-trust UI boundary, and the full CI/CD + monitoring stack. We have implemented and published an Activespace module (our Activepieces deployment on Cloud Run) on radmodules.dev that demonstrates how Google Cloud Run and other platform services support a production deployment with out-of-the-box guardrails.

The runtime: serverless that fits automation

Activepieces is webhook- and event-driven and idle most of the day, so Cloud Run's model fits perfectly:

• 🌐 Managed HTTPS URL — webhook endpoints reachable and trusted.
• ⚡ Autoscaling, including scale-to-zero — you pay for triggers, not idle time.
• 🔒 Runs on a private VPC — reaches Postgres without a public IP.

Platform Engineering: the golden path for automation teams

Before getting into individual guardrails, it's worth naming what this deployment model actually is: Platform Engineering. Instead of hand-rolling Cloud SQL, Secret Manager, IAP, and CI/CD for the Activepieces instance, a single parameterized module encodes all of it once. Users self-serve from a catalogue. The Activespace module on radmodules.dev demonstrates the paved-road / golden path concept — convention-over-configuration that enables anyone who deploys Activepieces to get a world-class engineering stack without filing infrastructure tickets.

The practical outcome: significant reduction in per-app provisioning time and cost savings per deployment compared to hand-wiring the stack manually (in our experience, around 95% less provisioning time per additional app once the shared foundation is in place). For a team running multiple Activepieces instances (per-customer, per-environment, or per-team), those numbers compound fast.

The guardrails, one by one

Backed-up state

Activepieces' flows and run history live in Cloud SQL for PostgreSQL — private IP, automated daily backups, point-in-time recovery, optional regional HA. The thing most likely to ruin your week (a self-managed DB) is managed for you.

A real queue for scaling

With Memorystore for Redis, Activepieces can run workers across multiple instances instead of in-process in one — the difference between a toy and a platform.

DevSecOps by construction

This is where Activepieces' specific threat model matters. The app accumulates credentials. Slack tokens, database passwords, API keys, OAuth refresh tokens for every connected service. Those secrets need to be treated as secrets:

• The encryption key, JWT secret, and database password are generated and stored in Secret Manager, injected at runtime. Nothing sensitive in the container image or your repo.
• The service account is scoped to exactly what it needs — secret access, Cloud SQL client, storage — and nothing more. No wildcard roles, no roles/editor shortcuts.

Least-privilege identity enforced by construction.

IAP on the builder UI. The Activepieces automation builder is a control plane for your entire integration surface — it holds live credentials for every connected service. Protecting it behind Identity-Aware Proxy means only authenticated, authorized Google identities reach it, with no credentials exposed to the public internet. This is zero-trust: the network perimeter is not your security boundary; verified identity is. No VPN to maintain, no auth plugin to configure in Activepieces itself. 🔐

Binary Authorization for container supply-chain risk. Activepieces ships with third-party "pieces" (plugins) — external JavaScript packages that execute inside your flows. That's a real supply-chain attack surface. Enabling Binary Authorization addresses the container layer of that risk: only images built and signed by your Cloud Build pipeline can be deployed to Cloud Run, so a tampered or substituted container image cannot be run. This is distinct from piece/npm-package risk (mitigated separately via network egress restrictions and pinning piece versions in your flow exports), but locking the container image supply chain is a meaningful structural control — and one you get without writing a policy from scratch.

VPC Service Controls + CMEK for regulated environments. For teams with data exfiltration requirements or compliance mandates (SOC 2, GDPR, HIPAA-adjacent), the deployment can layer on a VPC-SC perimeter network-level data exfiltration prevention, plus customer-managed encryption keys (CMEK) on Cloud SQL and storage. These are not checkbox items; they're structural controls.

SRE: SLOs and burn-rate alerting for your webhook receiver 📊

Not all Activepieces deployments need the same SLO. A well-structured SRE framing distinguishes two tiers:

A dropped webhook is a missed event, and missed events compound into broken business processes. If you're receiving webhooks from external systems, treat this as webhook-critical and engineer it as one:

• Fast burn at ~14× — page immediately, 5-minute window.
• Slow burn at ~6× — open a ticket, 1-hour window.

Cloud Run emits availability and latency metrics natively, so wiring this into Cloud Monitoring is straightforward. The key config decisions that enforce the webhook-critical SLO at the infrastructure level:

min_instance_count = 1     # keeps one instance warm — no cold-start on incoming webhooks
cpu_idle           = false # always-allocated CPU; combined with min_instance_count,
                           # eliminates in-instance startup delay

Scale-to-zero is fine for standard Activepieces deployments. But if you're receiving webhooks, keep one instance warm with CPU always allocated. The cost delta is small; the reliability delta is not.

DORA metrics: automation flows as code 🚀

Activepieces lets you export and version-control your automation flows. That's not just a backup strategy — it's a measurable DORA metric improvement:

Treating automation-as-code the same way you treat application code is the difference between "we have some Zapier flows" and "our automation platform has a deployment pipeline."

GitOps & IaC: reproducible by default

The entire Activepieces deployment is declared in Terraform (OpenTofu) — Cloud SQL, Redis, Secret Manager, IAM bindings, IAP config, Binary Authorization policy, monitoring, SLO alert policies. That means:

• Drift detection — any manual change to the running stack is visible on the next plan.
• Reproducibility — tofu apply from the same module at the same version produces the same infrastructure every time.
• Push-button rollback — roll back the entire stack, not just the container revision, by reverting the IaC commit.
• Blast-radius awareness — approval gates on destructive operations (destroy requires an explicit flag).

CI/CD: managed build + progressive delivery

No build servers to maintain. The pipeline is GitOps & CI/CD by construction:

1. Cloud Build builds the image on push.
2. Cloud Deploy promotes it through dev → staging → prod.
3. Each deploy creates an immutable revision with traffic splitting for canary rollouts.
4. One click to roll back when a flow change misbehaves.

Automated post-deploy steps (database migrations, initialization jobs) run as Cloud Run Jobs before traffic shifts. Safety gates prevent destructive operations from running unreviewed.

FinOps: pay for triggers, not idle 💸

Because Activepieces is idle most of the day, scale-to-zero is a real cost win — you pay for the seconds flows run, not 24/7 uptime. This is the headline FinOps advantage over hosted alternatives like Zapier or Make: no per-execution billing. You pay for compute, not for the number of automation runs — which matters enormously at scale.

More levers:

• Right-size container_resources; set min_instance_count only as high as your cold-start tolerance requires (1 if receiving webhooks, 0 otherwise).
• Billing budgets + alerts, labels for per-app cost attribution, and GCS/Artifact Registry lifecycle policies keep spend visible and bounded.

RAD Modules is the shortcut

Wiring private Cloud SQL + Redis + Secret Manager + IAM + IAP + Binary Auth + VPC-SC + CMEK + CI/CD + monitoring + SLO alerting around Activepieces is exactly the multi-day yak-shave this article is about avoiding. The RAD platform does it in a few clicks. The full list of provisioned services and every configuration input is in the Activepieces on Cloud Run guide.

Try it: radmodules.dev. Ship the automation, inherit the guardrails. 🚀