Por qué autoalojar Automatisch en un VPS
El gran argumento de Automatisch es el cumplimiento normativo. Mientras que Zapier o Make hacen transitar sus datos por servidores de terceros, a menudo fuera de la UE, Automatisch en self-hosting garantiza que nada sale de su VPS. Para una agencia o un despacho que maneja datos personales de clientes, es un argumento decisivo frente al RGPD. La herramienta se mantiene deliberadamente simple: un disparador (nuevo formulario, nuevo correo, webhook) y después una o varias acciones (enviar un mensaje, crear una fila, llamar a una API). El modelo resulta familiar para cualquiera que ya haya usado Zapier, lo que reduce la curva de aprendizaje. En un VPS con IP fija, sus webhooks entrantes y sus conexiones OAuth se mantienen estables y privados.
Beneficios concretos del self-hosting
- Cumplimiento del RGPD reforzado: los datos nunca salen de su servidor.
- Conexiones OAuth (Google, Slack, etc.) guardadas cifradas en su propia infraestructura.
- Interfaz familiar de disparador-acción, de manejo inmediato.
- Sin facturación por tarea: el volumen no hace subir la factura.
- IP fija para webhooks entrantes fiables y callbacks OAuth estables.
- Código open source auditable, ideal para tranquilizar a un cliente sobre la seguridad.
Requisitos técnicos
Automatisch se apoya en PostgreSQL y Redis para la cola de jobs. Un VPS de 2 vCPU y 2 GB de RAM basta para empezar; suba a 4 GB si multiplica los flujos activos y las ejecuciones concurrentes. Prevea 20 GB de disco, Docker y Docker Compose, un dominio (flow.sudominio.com) apuntando a la IP y los puertos 80/443 abiertos. Para las conexiones OAuth (Google, GitHub…), también deberá declarar la URL de callback HTTPS en la consola de desarrollador de cada servicio implicado.
Desplegar Automatisch con Docker
Preparar el VPS
Por SSH, instale Docker con
curl -fsSL https://get.docker.com | sh, cree/opt/automatischy sitúese dentro. Obtenga eldocker-compose.ymloficial desde el repositorio GitHub de Automatisch.Generar la clave de cifrado
Automatisch cifra las conexiones almacenadas. Genere la clave:
openssl rand -base64 36e indíquela enENCRYPTION_KEY, junto con unAPP_SECRET_KEY. Estas claves son críticas: guárdelas a buen recaudo, porque sin ellas sus conexiones quedan ilegibles.Configurar la URL y la base de datos
En el compose o en el
.env, fijeAPP_ENV=production,WEBHOOK_URL=https://flow.sudominio.comy la contraseña de PostgreSQL. Compruebe que los serviciospostgresyredisestán bien declarados.Arrancar el stack
Ejecute
docker compose up -d. El serviciomainlanza la migración de la base de datos y después el servidor web, mientras que un servicioworkerprocesa los jobs. Siga el proceso condocker compose logs -f main.Reverse proxy y SSL
Coloque Caddy o Traefik delante:
flow.sudominio.com { reverse_proxy localhost:3000 }. Aquí el HTTPS es imprescindible, porque los callbacks OAuth de los servicios de terceros exigen una URL de redirección segura.Crear el administrador y conectar una app
Abra la URL, cree la cuenta de administrador y añada después una primera conexión (por ejemplo un webhook o una cuenta de Google). Declare la URL de callback
https://flow.sudominio.com/...en la consola del servicio y pruebe un flujo disparador-acción completo.
Respalde sistemáticamente su ENCRYPTION_KEY y su base de datos PostgreSQL con el mismo rigor. La clave cifra todas las conexiones OAuth: si restaura una base de datos en un servidor nuevo sin la clave original, todas sus conexiones quedarán inservibles y habrá que volver a conectarlo todo. Programe un pg_dump diario automatizado (que además puede pilotar… con un flujo de Automatisch) y guarde el dump cifrado fuera del VPS.
