Tired of paying for automation tools that bill you for every single “run”?
Does the thought of opening ports, wrestling with NGINX or paying a subscription just to automate your repetitive tasks put you off?
Good news: you can run your own automation platform without paying a cent, without worrying about SSL certificates, without NGINX, and without exposing your infrastructure. Welcome to the power of open source plus smart DevOps.
By the end of this guide you’ll:
✅ Have ActivePieces self-hosted and running on your own server or VPS.
✅ Use Docker to keep the deployment clean and simple.
✅ Publish it on the internet over HTTPS thanks to Cloudflare Tunnels, without opening a single port.
✅ Enjoy unlimited runs and automations with no caps.
✅ Sleep easy: everything secure, private and under your control.
Why Bother Doing This?
SaaS automation platforms like Zapier, Make or Pabbly are great… until:
- You pay a premium for every extra step or webhook.
- You can’t host it on your own network.
- You want something that scales without depending on a third party.
ActivePieces is open source, powerful and modular. And once you deploy it yourself, it becomes a tool with zero cost and endless possibilities.
🧠 The Architecture in Brief
Your stack will be:
- ActivePieces: the automation platform.
- Docker + Docker Compose: a clean, controlled deployment.
- Cloudflare Tunnel: secure HTTPS access without touching your firewall.
- Zero licenses. Zero vendor lock-in. 100% yours.
🔧 What You’ll Need
- Linux (Ubuntu/Debian).
- Docker and Docker Compose installed (see this guide).
- A domain managed in Cloudflare (here I explain how to connect it).
- A subdomain for ActivePieces (e.g.
ap.tudominio.com). - A working Cloudflare Tunnel (I show you how in this guide).
🛠 Step by Step
1. Install Docker
sudo apt update && sudo apt upgrade -y
sudo apt install curl -y
curl -sSL https://get.docker.com/ | sh
sudo usermod -aG docker $USERWhat does this do?
It updates your system, installs curl, and downloads and installs Docker automatically. Then it adds your user to the docker group so you can use it without sudo. Log out and back in for the group change to take effect.
2. Clone and Deploy ActivePieces
git clone https://github.com/activepieces/activepieces.git
cd activepieces
sh tools/deploy.shWhat’s going on here?
We download the ActivePieces source code and run its deployment script. That automatically generates a .env file with the variables it needs and sets up the structure for Docker Compose.
3. Bring the Platform Up
docker compose -p activepieces up -dWhat does this command do?
It starts the containers (activepieces, postgres, redis) in the background (-d) under the activepieces project. The whole application ends up running on your local server.
Check that they’re running:
docker compose -p activepieces psOpen this in your browser:
http://IP_DEL_SERVIDOR:8080
4. Create your ActivePieces user account
Once you go to the address:
http://IP_DEL_SERVIDOR:8080
you’ll get a sign-up screen like this one:
Fill in the required fields (name, email and password) to create a local account. You’ll use this account to get into the admin panel and manage all your automation flows.
This step confirms the platform deployed correctly and is up and running in your local environment. It isn’t reachable from the internet yet, though, and it isn’t ready to receive external webhooks.
5. Safe public exposure and working webhooks
So far your instance is only reachable from your local network. There’s one critical limitation, though:
By default, ActivePieces will try to use the server’s public IP to build the webhook URLs.
That gets messy if you’re running the platform on a personal machine, behind NAT, or without DNS properly configured, because external tools won’t be able to reach the webhook URLs it generates.
What does that mean in practice?
Any flow that relies on webhooks (receiving data from Stripe, GitHub or a form, for example) won’t work properly if the generated URL points to an IP that can’t be resolved or reached from outside.
To solve this safely and efficiently, we’re going to:
- Expose ActivePieces over HTTPS using Cloudflare Tunnel, without opening ports.
- Set the
AP_FRONTEND_URLparameter to a public subdomain.
🌍 Publishing It over HTTPS Without Opening Ports
Now that we’ve spotted the problem with the webhook URLs (which point to localhost by default), let’s fix it properly. We’ll use this step to hit two key goals:
- Expose ActivePieces publicly and securely over HTTPS.
- Set the frontend URL so that webhooks are reachable from the internet.
For that we’ll use a reliable, well-known tool: Cloudflare Tunnel.
Here’s a detailed guide on installing and configuring it:
👉 Expose your internal services with a Cloudflare Tunnel (free)
In this tutorial we’ll assume the tunnel is already configured and running on the server where ActivePieces is deployed.
Remember that ActivePieces is listening on port 8080
Now go to:https://ap.tudominio.com
Checking public access: ActivePieces is now reachable from the internet
With the Cloudflare Tunnel configured, you can confirm your instance is reachable from anywhere by visiting the subdomain you set up.
When you open it you should see the usual ActivePieces sign-up interface, but now served securely over HTTPS through the tunnel:
This confirms the tunnel is working properly, and that we no longer depend on the local network or have to expose any ports.
The critical detail: the webhooks still point to localhost
Even though the interface is published and reachable from outside, one key thing is still unresolved: the webhooks it generates still point to http://localhost:8080, as you can see in the screenshot below:
With this default configuration, any external system that tries to call the webhook (Stripe, Slack, Notion and so on) can’t reach the server, because the generated URL isn’t valid outside the local environment.
📬 Webhooks That Actually Work
To fix this behavior we have to explicitly define the AP_FRONTEND_URL environment variable, which tells ActivePieces the public base URL it should use to build links, webhooks included.
How to do it:
- Open the
.envfile in the project directory:
nano .env- Find this line:
AP_FRONTEND_URL=- And update it with your tunnel’s URL, in this case:
AP_FRONTEND_URL=https://ap.itrafa.com- Save and close the file. (Ctrl + X)
- Apply the changes by restarting the containers:
docker compose -p activepieces up -dFrom this point on, every new webhook your flows generate will use the public URL correctly, so your automations can work reliably with external tools.
🔄 What About Updates?
Always up to date with a single command:
sh tools/update.sh🚀 Why This Approach Wins
✅ Unlimited runs. Unlimited flows.
✅ Zero cost, no licenses and no artificial limits.
✅ No manual certificates.
✅ Automatic HTTPS, enterprise-grade security.
✅ No open ports. No needless risk.
✅ Full control over your data, your processes and your environment.
💡 Ideal for…
- Freelancers who want to automate without paying for licenses.
- Sysadmins and DevOps people who value control.
- MSPs that want to offer automation to their clients as a service.
- Companies that don’t want to depend on external platforms.
TL;DR
| Component | Why it matters |
|---|---|
| ActivePieces | Powerful, open source automation. |
| Docker | Clean, portable deployment. |
| Cloudflare Tunnel | HTTPS without opening ports. Security without the hassle. |
| Cost | No licences, no subscriptions. You provide the infrastructure: a VPS or a machine running 24/7. |
🎯 Automate Everything. Pay Nothing. No Limits.
This isn’t an experiment, it’s a professional solution that’s ready for production.
And the best part: you’re not tied to anyone. It’s yours. Run it wherever you like.
Ready to take control of your automations?
Alternative: automation without a server
If your site runs on WordPress and you want something simpler that needs no Docker and no extra infrastructure, take a look at Bit Flows as an automation alternative inside WordPress. It’s less powerful than ActivePieces, but it runs directly in your WordPress install with no external dependencies.