VPS para Activepieces: automatización propia

Los servicios de automatización alojados cobran por tarea, y el contador corre incluso con cosas que ni siquiera son trabajo. Un flujo que revisa un feed cada cinco minutos son 8640 ejecuciones al mes antes de haber hecho nada útil. Ejecuta ese mismo flujo en tu propio servidor y la factura es el servidor.

Activepieces es un constructor de automatizaciones de código abierto: disparadores, pasos, ramas, unos cientos de integraciones listas para usar y pasos de código cuando las integraciones no alcanzan. La edición community tiene licencia MIT y funciona bien en un servidor pequeño con Docker Compose.

Qué plan

Lo instalamos en un servidor de prueba y medimos. El archivo compose de serie arranca la app y cinco workers: unos 2,6–3 GB de RAM junto con Postgres y Redis. Con un solo worker baja a cerca de 1,6 GB.

Elige un plan con su propia IPv4. Los webhooks son la razón principal para alojar esto tú mismo, y los servicios que los llaman deben llegar a los puertos 80 y 443; en los planes NAT solo el puerto SSH es accesible desde fuera. Las ubicaciones son Alemania y Finlandia; la disponibilidad se ve al hacer el pedido. Puedes pagar con cripto, sin KYC.

Instalación

Primero apunta un dominio —por ejemplo flows.example.com— al servidor. Luego, como root en 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 a .env y rellena secretos aleatorios. Antes del primer arranque, cambia dos líneas de .env y una del archivo 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

La que importa es la primera línea. AP_FRONTEND_URL no sirve solo para los enlaces de la interfaz: los workers se conectan a la app a través de ella. Si la dejas en http://localhost:8080, cada contenedor worker busca la app dentro de sí mismo, no la encuentra y tus flujos nunca se publican. Nos pasó exactamente eso: «Socket.IO connection error» en los logs del worker, una publicación colgada y webhooks respondiendo 404. Con el dominio real, el mismo flujo se publicó y el webhook se ejecutó.

El sed sobre docker-compose.yml deja el puerto 8080 en localhost. Los puertos que publica Docker se saltan ufw; sin esa línea, la app quedaría abierta en un puerto desnudo al lado de tu HTTPS.

En Micro-IP, baja además a un solo worker:

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

Ahora HTTPS y el arranque:

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

Espera medio minuto, abre https://flows.example.com y crea tu cuenta enseguida. Quien se registra primero es dueño de la plataforma; después, el registro es solo por invitación.

Comprueba que los webhooks funcionan

Crea un flujo con el disparador Webhook (Catch Webhook), añade cualquier paso y publícalo. El panel del disparador muestra la URL. Envíale un evento de prueba:

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

Deberías recibir un 200, y la ejecución aparece en Runs como correcta. Si recibes 404, vuelve a revisar AP_FRONTEND_URL.

El día a día

• Actualizaciones. El archivo compose fija una versión exacta (0.92.2 al escribir esto). Cambia la etiqueta en docker-compose.yml y luego docker compose -p activepieces pull && docker compose -p activepieces up -d. Echa antes un vistazo a las notas de versión; a las herramientas de automatización les encanta renombrar cosas.
• Copias de seguridad. Los flujos, las conexiones y el historial de ejecuciones viven en el volumen de Postgres. Haz un dump de forma programada y guarda la copia fuera del servidor: las conexiones contienen tus tokens de API de otros servicios.
• Los pasos de código no están en sandbox en esta configuración (AP_EXECUTION_MODE=UNSANDBOXED). Es tu servidor y son tus flujos, así que es aceptable. Deja de serlo en el momento en que permites construir flujos a gente en la que no confías.

Si ya conoces n8n, la idea es la misma: mira VPS para n8n. Elige el editor en el que te resulte más fácil pensar; los dos van bien en los mismos planes.

Relacionado

• VPS para n8n: la otra gran herramienta de automatización autoalojada
• Varios servicios en un solo VPS: Activepieces junto a tu app y un panel, una sola IP
• VPS para Docker
• Cómo añadir swap en un VPS
• Cómo configurar un cortafuegos ufw