Deploy and Host Automatisch on Railway

Built for an LLM agent to deploy and use. The deploy form has no fields to fill: the admin password, the encryption key and the signing secrets are all generated, and the first admin is created at boot from variables, so nobody opens a setup page or keeps upstream's well-known default login. Automatisch is an open-source Zapier alternative: build multi-step workflows ("flows") that connect apps, with a visual editor, webhook triggers and a background worker.

About Hosting Automatisch

This template runs four services: Postgres (flows, connections, execution history, on a volume), Redis (the job queue, on a volume), the automatisch web and API service, and a worker that runs the same image with WORKER=true and executes the flows. Postgres and Redis are private; only the web service has a public domain.

No default login. Upstream seeds user@automatisch.io with the password sample on first boot, which on a public URL is an open door. This template's image seeds the first admin from ADMIN_EMAIL (admin@ plus the service domain) and ADMIN_PASSWORD (a generated secret) instead, and the upstream default login is rejected. Change the email or password in the app afterwards and the new values stay; the variables only matter on an empty database.

What persists. Flows, connections and execution history live in Postgres on a volume mounted at /var/lib/postgresql; the queue lives in Redis on a volume mounted at /data. Redeploys keep both, and the encryption key that protects stored connection credentials is a stable variable, so saved connections keep working.

The API. Automatisch's documented public REST API (/api/v1) is behind an enterprise licence upstream, so it answers 404 without a licence. The same internal API the web interface uses is available and works with the open-source image: log in with POST /internal/api/v1/access-tokens to get a token, then send it in the Authorization header. That is what the contract below uses.

Agent contract

Public URL: https://RAILWAY_PUBLIC_DOMAIN (the generated domain of the automatisch service)
Private URL: http://automatisch.railway.internal:8080
Credentials: the variables ADMIN_EMAIL and ADMIN_PASSWORD, set on the automatisch service
Auth: POST /internal/api/v1/access-tokens with JSON {"email","password"} returns data.token; send it as the Authorization header (no Bearer prefix). Without it every internal API call answers 401
Health: GET /healthcheck returns 200

# needs: SITE_URL (public https URL of the automatisch service), ADMIN_EMAIL and ADMIN_PASSWORD (its variables); also curl, sed
curl -s -o /dev/null -w "health: %{http_code}\n" "$SITE_URL/healthcheck"
TOKEN=$(curl -s -X POST "$SITE_URL/internal/api/v1/access-tokens" -H 'content-type: application/json' -d "{\"email\":\"$ADMIN_EMAIL\",\"password\":\"$ADMIN_PASSWORD\"}" | sed -n 's/.*"token":"\([^"]*\)".*/\1/p')
curl -s -o /dev/null -w "login with default seed user: %{http_code}\n" -X POST "$SITE_URL/internal/api/v1/access-tokens" -H 'content-type: application/json' -d '{"email":"user@automatisch.io","password":"sample"}'
curl -s -o /dev/null -w "read without key: %{http_code}\n" "$SITE_URL/internal/api/v1/flows"
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X POST "$SITE_URL/internal/api/v1/flows" -H 'content-type: application/json' -d '{}'
curl -s -o /dev/null -w "write wrong key: %{http_code}\n" -X POST "$SITE_URL/internal/api/v1/flows" -H 'content-type: application/json' -H 'Authorization: wrong' -d '{}'
FLOW=$(curl -s -X POST "$SITE_URL/internal/api/v1/flows" -H "Authorization: $TOKEN" -H 'content-type: application/json' -d '{}' | sed -n 's/.*"data":{"id":"\([^"]*\)".*/\1/p')
echo "flow created: $FLOW"
curl -s -H "Authorization: $TOKEN" "$SITE_URL/internal/api/v1/flows/$FLOW" | sed -n 's/.*"status":"\([^"]*\)".*/flow status: \1/p'; echo
curl -s -o /dev/null -w "flow delete: %{http_code}\n" -X DELETE -H "Authorization: $TOKEN" "$SITE_URL/internal/api/v1/flows/$FLOW"

A fresh deploy prints health: 200, login with default seed user: 422, read without key: 401, write without key: 401, write wrong key: 401, a created flow id, flow status: incomplete and flow delete: 204.

Why Deploy Automatisch on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying Automatisch on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Agent-ready - no deployer fields, a contract block and one script that proves login, flow creation and refusal without a key.
No default credentials - the admin is created from a generated secret; upstream's well-known login is rejected.
Data survives redeploys - volumes on Postgres and Redis, stable encryption key.
Pinned - the image is pinned by digest.
Zapier-style automation you own - no per-task pricing, flows and credentials stay on your own service.

Common Use Cases

Connect apps without code - trigger on a webhook or a schedule and push data between SaaS tools.
Self-hosted Zapier replacement - keep workflow data and connection secrets on your own infrastructure.
Agent-driven automations - an agent creates and manages flows through the internal API.
Notifications and syncing - route form submissions, alerts and records to chat, email and sheets.

Dependencies for Automatisch Hosting

Postgres and Redis, both included in this template as private services. A custom domain is optional.

Deploy Automatisch | (Just Updated) Zapier Alternative, Open-Source Workflow Automation, Admin Set at Boot