Self-Host Activepieces with Greffon
A no-code automation builder is glue between every account you have. Running it on a box you own keeps those connection secrets off a vendor's servers. Here is the honest setup.
Automation tools are quietly some of the most privileged software you run. To wire two services together, they hold credentials to both, and every flow you build runs through them. Activepieces is an open-source no-code builder in the same shape as Zapier or Make, and self-hosting it answers a fair question: where do all those connection secrets actually live? On a greffer, the answer is a machine you own. Greffon takes the plumbing off your plate.
Why own your automations
Activepieces lets you build flows visually: a trigger fires (a webhook, a schedule, a new row somewhere) and a chain of steps runs. The catch is that each connected piece stores an API token or OAuth grant, and those tokens are as good as the accounts they unlock. On a hosted plan those secrets sit on someone else's infrastructure. Self-hosting moves them onto hardware you control, and the catalog greffon encrypts stored connection credentials with a key the platform generates for your instance.
It is also a real cost lever. Hosted automation tools meter on task runs, and a few chatty flows can climb a pricing tier fast. A greffon you own runs as many tasks as your hardware can handle, with no per-task counter.
Graft it from the catalog
On a greffer you do not hand-write a compose file or wire a reverse proxy. Pick Activepieces from the catalog and graft it onto your greffer. Greffon issues the certificate and routes the app, so it comes up reachable over HTTPS. The encryption key and the JWT secret that signs auth tokens are generated for your instance at creation, so you are not copying secrets out of a README into an env file by hand.
Webhooks and the public URL
Most useful automations start with a webhook: an outside service POSTs to a URL when something happens. That only works if the service can reach your greffer, and Activepieces builds those webhook URLs from its public URL setting, which Greffon points at the instance address for you.
For a greffer behind NAT or CGNAT with no public IP, tunnel mode is the honest answer here. The greffer connects outbound to the manager's tunnel and serves the app over HTTPS with no inbound ports opened, and because Activepieces is an ordinary HTTP app the tunnel carries it fine. If you would rather expose the greffer directly, port forwarding plus dynamic DNS also works. Either way the webhook endpoints stay reachable over HTTPS so the services you connect can deliver to them.
Why it has to stay on
An automation tool is only doing its job when it is running. A scheduled flow that should fire at 2am does not fire if the box is asleep, and a webhook delivered while the greffer is down is usually gone: many services retry for a while, but not forever. Run Activepieces on an always-on greffer, a small VPS, a mini-PC, or a free Oracle Cloud box, rather than a laptop that sleeps. The Oracle walkthrough is a good way to get a greffer running before you graft this onto it.
Resource-wise, Activepieces is heavier than a single small service: it runs a database and a worker that spins up sandboxes to execute flow steps. Give it real headroom (a couple of gigabytes of RAM is a sane floor) rather than the smallest instance you can find, especially if you expect AI steps or busy flows.
Back up the credentials
The thing you cannot afford to lose is not the flow diagrams, it is the connection credentials and the encryption key that unlocks them. Lose the key and every stored connection is dead weight you have to re-authorize by hand. Greffon handles TLS and routing today, and native one-click backups are coming in M2. Until then, bring your own backup tool (restic or borgbackup are the usual choices), back up the Activepieces data on a schedule, and keep a copy off the greffer.
