VPS per Activepieces: automazione in casa

I servizi di automazione in hosting fanno pagare per task, e il contatore gira anche su cose che non sono nemmeno lavoro. Un flow che controlla un feed ogni cinque minuti fa 8.640 esecuzioni al mese prima ancora di aver fatto qualcosa di utile. Fai girare lo stesso flow sul tuo server e la bolletta è il server.

Activepieces è un builder di automazioni open source: trigger, passi, rami, qualche centinaio di integrazioni pronte e passi di codice quando quelle pronte non bastano. La community edition è sotto licenza MIT e gira tranquillamente su un piccolo server con Docker Compose.

Quale piano

L'abbiamo installato su un server di prova e misurato. Il file compose di serie avvia l'app e cinque worker: circa 2,6–3 GB di RAM insieme a Postgres e Redis. Con un solo worker si scende a circa 1,6 GB.

Scegli un piano con un IPv4 tutto suo. I webhook sono il motivo principale per ospitarlo da sé, e i servizi che li chiamano devono raggiungere le porte 80 e 443; sui piani NAT dall'esterno si raggiunge solo la porta SSH. Le località sono Germania e Finlandia; la disponibilità si vede al momento dell'ordine. Puoi pagare in cripto, senza KYC.

Installazione

Prima punta un dominio, per esempio flows.example.com, sul server. Poi, come root su Ubuntu 24.04 o Debian 12:

curl -fsSL https://get.docker.com | sh
git clone --depth 1 https://github.com/activepieces/activepieces.git
cd activepieces
sh tools/deploy.sh

deploy.sh copia .env.example in .env e inserisce segreti casuali. Prima del primo avvio cambia due righe in .env e una nel file compose:

sed -i 's|^AP_FRONTEND_URL=.*|AP_FRONTEND_URL=https://flows.example.com|; s|^AP_TELEMETRY_ENABLED=.*|AP_TELEMETRY_ENABLED=false|' .env
sed -i "s|- '8080:80'|- '127.0.0.1:8080:80'|" docker-compose.yml

Quella che conta è la prima riga. AP_FRONTEND_URL non serve solo per i link nell'interfaccia: i worker si collegano all'app attraverso di essa. Lasciala a http://localhost:8080 e ogni container worker cerca l'app dentro sé stesso, non la trova, e i tuoi flow non vengono mai pubblicati. È successo proprio a noi: «Socket.IO connection error» nei log del worker, una pubblicazione appesa e webhook che rispondevano 404. Con il dominio vero, lo stesso flow si è pubblicato e il webhook è partito.

Il sed su docker-compose.yml tiene la porta 8080 su localhost. Le porte pubblicate da Docker scavalcano ufw; senza questa riga l'app sarebbe aperta su una porta nuda accanto al tuo HTTPS.

Su Micro-IP, scendi anche a un solo worker:

sed -i 's/replicas: 5/replicas: 1/' docker-compose.yml

Ora HTTPS e l'avvio:

apt install -y caddy
cat > /etc/caddy/Caddyfile <<'EOF'
flows.example.com {
    reverse_proxy 127.0.0.1:8080
}
EOF
systemctl reload caddy
ufw allow 22/tcp && ufw allow 80/tcp && ufw allow 443/tcp && ufw enable
docker compose -p activepieces up -d

Aspetta mezzo minuto, apri https://flows.example.com e crea subito il tuo account. Chi si registra per primo possiede la piattaforma; dopo, si entra solo su invito.

Verifica che i webhook funzionino

Crea un flow con il trigger Webhook (Catch Webhook), aggiungi un passo qualsiasi e pubblicalo. Il pannello del trigger mostra l'URL. Mandagli un evento di prova:

curl -X POST https://flows.example.com/api/v1/webhooks/YOUR_FLOW_ID \
  -H 'content-type: application/json' \
  -d '{"event":"payment.paid","amount":16}'

Dovresti ricevere un 200, e l'esecuzione compare in Runs come riuscita. Se invece ricevi 404, torna a controllare AP_FRONTEND_URL.

Nella gestione quotidiana

• Aggiornamenti. Il file compose fissa una versione esatta (0.92.2 al momento della scrittura). Cambia il tag in docker-compose.yml, poi docker compose -p activepieces pull && docker compose -p activepieces up -d. Dai prima un'occhiata alle release notes; gli strumenti di automazione adorano rinominare le cose.
• Backup. Flow, connessioni e storico delle esecuzioni vivono nel volume di Postgres. Fanne un dump a intervalli regolari e tieni la copia fuori dal server: le connessioni contengono i tuoi token API per altri servizi.
• I passi di codice non sono in sandbox in questa configurazione (AP_EXECUTION_MODE=UNSANDBOXED). È il tuo server e sono i tuoi flow, quindi è accettabile. Smette di esserlo nel momento in cui lasci costruire flow a persone di cui non ti fidi.

Se conosci già n8n, l'idea è la stessa: vedi VPS per n8n. Scegli l'editor in cui ti viene più facile ragionare; entrambi stanno bene sugli stessi piani.

Correlati

• VPS per n8n: l'altro grande strumento di automazione self-hosted
• Più servizi su un solo VPS: Activepieces accanto alla tua app e a una dashboard, un solo IP
• VPS per Docker
• Come aggiungere swap su un VPS
• Come configurare un firewall ufw