VPS pour Activepieces : l'automatisation chez vous

Les services d'automatisation hébergés facturent à la tâche, et le compteur tourne même pour ce qui n'est pas vraiment du travail. Un flow qui vérifie un flux toutes les cinq minutes, c'est 8 640 exécutions par mois avant même d'avoir fait quoi que ce soit d'utile. Faites tourner le même flow sur votre serveur, et la facture, c'est le serveur.

Activepieces est un outil d'automatisation open source : déclencheurs, étapes, branches, quelques centaines d'intégrations prêtes à l'emploi, et des étapes de code quand celles-ci ne suffisent plus. L'édition communautaire est sous licence MIT et tourne sans problème sur un petit serveur avec Docker Compose.

Quelle offre

Nous l'avons installé sur un serveur de test et mesuré. Le fichier compose fourni lance l'application et cinq workers : environ 2,6 à 3 Go de RAM avec Postgres et Redis. Avec un seul worker, on descend vers 1,6 Go.

Prenez une offre avec sa propre IPv4. Les webhooks sont la raison principale d'héberger cet outil soi-même, et les services qui les appellent doivent atteindre les ports 80 et 443 ; sur les offres NAT, seul le port SSH est joignable de l'extérieur. Les emplacements sont l'Allemagne et la Finlande — la disponibilité s'affiche à la commande. Paiement en crypto possible, sans KYC.

Installation

Pointez d'abord un domaine — disons flows.example.com — vers le serveur. Puis, en root sur Ubuntu 24.04 ou 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 copie .env.example vers .env et remplit des secrets aléatoires. Avant le premier démarrage, modifiez deux lignes de .env et une du fichier 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

C'est la première ligne qui compte. AP_FRONTEND_URL ne sert pas qu'aux liens de l'interface : les workers se connectent à l'application par cette adresse. Laissez http://localhost:8080 et chaque conteneur worker cherche l'application en lui-même, ne la trouve pas, et vos flows ne se publient jamais. C'est exactement ce qui nous est arrivé : « Socket.IO connection error » dans les logs du worker, une publication bloquée et des webhooks qui répondaient 404. Avec le vrai domaine, le même flow s'est publié et le webhook a fonctionné.

Le sed sur docker-compose.yml garde le port 8080 sur localhost. Les ports publiés par Docker contournent ufw ; sans cela, l'application serait ouverte sur un port brut à côté de votre HTTPS.

Sur Micro-IP, passez aussi à un seul worker :

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

Maintenant HTTPS et le démarrage :

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

Attendez une trentaine de secondes, ouvrez https://flows.example.com et créez votre compte tout de suite. La première inscription possède la plateforme ; ensuite, l'inscription se fait uniquement sur invitation.

Vérifier que les webhooks fonctionnent

Créez un flow avec le déclencheur Webhook (Catch Webhook), ajoutez une étape quelconque, publiez-le. Le panneau du déclencheur affiche l'URL. Envoyez-lui un événement de test :

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

Vous devriez obtenir un 200, et l'exécution apparaît dans Runs comme réussie. Si vous obtenez 404, revenez vérifier AP_FRONTEND_URL.

Au quotidien

• Mises à jour. Le fichier compose fixe une version exacte (0.92.2 au moment de la rédaction). Changez le tag dans docker-compose.yml, puis docker compose -p activepieces pull && docker compose -p activepieces up -d. Parcourez d'abord les notes de version ; les outils d'automatisation adorent renommer les choses.
• Sauvegardes. Les flows, les connexions et l'historique d'exécution vivent dans le volume Postgres. Faites-en un dump régulier et gardez la copie hors du serveur — les connexions contiennent vos jetons API pour d'autres services.
• Les étapes de code ne sont pas en sandbox dans cette configuration (AP_EXECUTION_MODE=UNSANDBOXED). C'est votre serveur et ce sont vos flows, donc c'est acceptable. Ça cesse de l'être dès que vous laissez construire des flows à des personnes en qui vous n'avez pas confiance.

Si vous connaissez déjà n8n, l'idée est la même — voir VPS pour n8n. Choisissez l'éditeur dans lequel vous réfléchissez le plus facilement ; les deux se plaisent sur les mêmes offres.

Sur le même sujet

• VPS pour n8n — l'autre grand outil d'automatisation auto-hébergé
• Plusieurs services sur un seul VPS — Activepieces à côté de votre app et d'un tableau de bord, une seule IP
• VPS pour Docker
• Ajouter du swap sur un VPS
• Configurer un pare-feu ufw