Why self-host Automatisch on a VPS
Automatisch's main selling point is compliance. Where Zapier or Make route your data through third-party servers often outside the EU, Automatisch in self-hosting guarantees that nothing leaves your VPS. For an agency or a firm handling clients' personal data, this is a decisive argument with respect to GDPR. The tool remains deliberately simple: a trigger (a new form, a new email, a webhook) then one or more actions (send a message, create a row, call an API). The model is familiar to anyone who has already used Zapier, which reduces the learning curve. On a VPS with a fixed IP, your incoming webhooks and your OAuth connections stay stable and private.
Concrete benefits of self-hosting
- Strengthened GDPR compliance: data never leaves your server.
- OAuth connections (Google, Slack, etc.) stored encrypted on your side.
- Familiar trigger-action interface, immediate to get to grips with.
- No per-task billing: volume does not drive up the bill.
- Fixed IP for reliable incoming webhooks and stable OAuth callbacks.
- Auditable open source code, ideal for reassuring a client about security.
Technical requirements
Automatisch relies on PostgreSQL and Redis for the job queue. A VPS with 2 vCPU and 2 GB of RAM is fine to start; move up to 4 GB if you multiply active flows and concurrent executions. Plan for 20 GB of disk, Docker and Docker Compose, a domain (flow.yourdomain.com) pointing to the IP, and ports 80/443 open. For OAuth connections (Google, GitHub…), you will also need to declare the HTTPS callback URL in each developer console of the services concerned.
Deploy Automatisch with Docker
Prepare the VPS
Over SSH, install Docker via curl -fsSL https://get.docker.com | sh, create /opt/automatisch and move into it. Fetch the official docker-compose.yml from the Automatisch GitHub repository.
Generate the encryption key
Automatisch encrypts the stored connections. Generate the key: openssl rand -base64 36 and set it in ENCRYPTION_KEY, along with an APP_SECRET_KEY. These keys are critical: back them up, without them your connections become unreadable.
Configure the URL and the database
In the compose or the .env, set APP_ENV=production, WEBHOOK_URL=https://flow.yourdomain.com and the PostgreSQL password. Check that the postgres and redis services are properly declared.
Launch the stack
Run docker compose up -d. The main service launches the database migration then the web server, while a worker service processes the jobs. Follow along with docker compose logs -f main.
Reverse proxy and SSL
Place Caddy or Traefik in front: flow.yourdomain.com { reverse_proxy localhost:3000 }. HTTPS is essential here, because the OAuth callbacks of third-party services require a secure redirect URL.
Create the admin and connect an app
Open the URL, create the administrator account, then add a first connection (for example a webhook or a Google account). Declare the callback URL https://flow.yourdomain.com/... in the service's console, and test a complete trigger-action flow.
Systematically back up your ENCRYPTION_KEY and your PostgreSQL database with the same rigor. The key encrypts all OAuth connections: if you restore a database on a new server without the original key, all your connections will be unusable and everything will need to be reconnected. Set up an automated daily pg_dump (which you can, incidentally, drive… with an Automatisch flow) and store the encrypted dump off the VPS.
