automatisch/automatisch
The open source Zapier alternative. Build workflow automation without spending time and money.
12 hidden assumptions · 5-stage pipeline · 8 components
Like any codebase, this repository makes assumptions it never checks — most are routine. The ones worth your attention are below.
Self-hosted workflow automation platform connecting apps through triggers and actions
External services send webhook triggers to the system, which validates the payload, looks up matching workflows, and executes them step-by-step through a Bull queue. Each step authenticates with external services using stored connections, performs the configured action (API call, data transformation, agent execution), and passes the output to the next step until the workflow completes.
Under the hood, the system uses 2 feedback loops, 3 data pools, 4 control points to manage its runtime behavior.
A 8-component repository. 2733 files analyzed. Data flows through 5 distinct pipeline stages.
Hidden Assumptions
Most of what this code assumes is routine. These 3 are the ones most likely to cause trouble here. The rest are minor; they're under "Show everything".
If requestBodySizeLimit is undefined, misconfigured, or exceeds available memory, the server could crash with OOM errors when processing large webhook payloads or silently use Express defaults that are too small
Webhook validation that requires raw request bodies (like signature verification) will fail silently or throw undefined errors if the body parsing middleware doesn't run or fails
A malformed prompt or model issue could cause runAgent() to hang indefinitely or consume excessive memory, blocking the Bull queue worker and preventing other workflows from executing
Show everything (9 more)
The Agent model exists and the database connection is available when this action runs, but doesn't handle the case where the .ee. enterprise module isn't loaded
If this fails: In non-enterprise deployments, importing Agent from agent.ee.js will throw module not found errors, causing the entire agents app to fail loading and breaking workflow execution
packages/backend/src/apps/agents/actions/run-agent/index.js:Agent.query
The $.agents.getAll() method returns an array of objects with 'id' and 'name' properties, but never validates the structure of returned agents
If this fails: If the agents service returns malformed data or the properties are named differently, the map() operation will produce dropdown options with undefined values, breaking the UI agent selection
packages/backend/src/apps/agents/dynamic-data/list-agents/index.js:$.agents.getAll()
Users will enter instanceUrl in the format 'https://subdomain.airbrake.io' as described, but no validation ensures the URL follows this pattern or is a valid URL
If this fails: Invalid URLs will be stored as connection auth data and cause API calls to fail with confusing network errors instead of clear validation messages during connection setup
packages/backend/src/apps/airbrake/auth/index.js:instanceUrl field
The Airbrake auth token remains valid indefinitely once entered, with no expiration handling or refresh mechanism
If this fails: When tokens expire or are revoked, workflows will start failing with authentication errors but the system won't proactively detect or handle token refresh, requiring manual user intervention
packages/backend/src/apps/airbrake/auth/index.js:authToken field
The agentId parameter from $.step.parameters.agentId is always a valid UUID that exists in the database, trusting the dropdown selection mechanism
If this fails: If the agent is deleted between workflow creation and execution, or if the parameter is corrupted, Agent.query().findOne() returns null and runAgent(null) will throw undefined errors
packages/backend/src/apps/agents/actions/run-agent/index.js:$.step.parameters
The passport configuration will successfully set up all OAuth strategies and session handling without checking if required environment variables (CLIENT_ID, CLIENT_SECRET) are present
If this fails: Missing OAuth credentials cause passport strategies to fail silently during initialization, leading to authentication routes returning 500 errors instead of configuration errors
packages/backend/src/app.js:configurePassport call
The number of agents returned by getAll() will be reasonable for dropdown display, with no pagination or limits applied
If this fails: With hundreds of agents, the dropdown becomes unusable and the HTTP response size grows large, potentially causing browser performance issues or request timeouts
packages/backend/src/apps/agents/dynamic-data/list-agents/index.js:$.agents.getAll()
The agentResult returned by runAgent() is always a serializable object that can be stored in the database as JSON
If this fails: If runAgent() returns circular references, functions, or other non-JSON types, $.setActionItem() will fail with serialization errors and the workflow step will crash
packages/backend/src/apps/agents/actions/run-agent/index.js:$.setActionItem
Agents never require external authentication or connection management, assuming they always use internal system credentials
If this fails: If agents need to access external APIs with user-specific credentials, the current architecture provides no way to associate connections with agent executions, limiting agent capabilities
packages/backend/src/apps/agents/index.js:supportsConnections: false
Open the standalone hidden-assumptions report for automatisch →
How Data Flows Through the System
External services send webhook triggers to the system, which validates the payload, looks up matching workflows, and executes them step-by-step through a Bull queue. Each step authenticates with external services using stored connections, performs the configured action (API call, data transformation, agent execution), and passes the output to the next step until the workflow completes.
- Receive webhook trigger — External services POST webhook payloads to /webhooks/:flowId endpoint, where the router validates the payload against the trigger schema and extracts event data [TriggerPayload]
- Queue workflow execution — The system creates a WorkflowExecution record, enqueues it in the Bull Redis queue system, and returns immediate response to the webhook sender
- Execute workflow steps — Bull workers dequeue executions and process each step by loading the Connection for authentication, creating an ActionContext with $.auth.data and $.step.parameters, then calling the action's run() function [WorkflowExecution → StepExecution]
- Perform external API calls — Each step's action function uses the authenticated $.http client to call external service APIs, transform data, or execute AI agents, then calls $.setActionItem() to store the output [ActionContext → StepExecution]
- Store execution results — Completed steps update their StepExecution records with data_out or error_details, and the overall WorkflowExecution status is updated to completed or failed [StepExecution]
Data Models
The data structures that flow between stages — the contracts that hold the system together.
packages/backend/src/models/Database model with id: UUID, flow_id: UUID, status: enum(running|completed|failed), steps: JSON array of executed steps, created_at: timestamp, updated_at: timestamp
Created when a trigger fires, updated as each step executes, marked complete/failed when workflow finishes
packages/backend/src/models/Database model with execution_id: UUID, step_id: UUID, status: enum(running|completed|failed), data_in: JSON, data_out: JSON, error_details: text
Created for each step in a workflow, populated with input data, executed via app action, stores output data or error details
packages/backend/src/models/Database model with id: UUID, key: string, app_key: string, app_auth_client_id: string, verified: boolean, auth_data: encrypted JSON with tokens/credentials
Created during OAuth flow or manual credential entry, stores encrypted auth tokens, verified periodically, used for API calls
packages/backend/src/helpers/define-action.jsRuntime object with $.auth.data: decrypted connection credentials, $.step.parameters: user-configured values, $.http: authenticated HTTP client, $.setActionItem(): function to set step output
Constructed for each step execution with auth context and parameters, passed to action run() function, destroyed after step completes
packages/backend/src/apps/JSON object varying by app - webhook payload from external service containing event data like {user_id, action, timestamp, resource_data}
Received from external service webhook, validated against trigger schema, used to populate workflow variables
packages/backend/src/helpers/define-app.jsObject with name: string, key: string, auth: {fields: array, verifyCredentials: function}, triggers: array of trigger definitions, actions: array of action definitions
Loaded at startup from app modules, registered in system, used to validate connections and execute triggers/actions
System Behavior
How the system operates at runtime — where data accumulates, what loops, what waits, and what controls what.
Data Pools
PostgreSQL database storing workflows, executions, connections, and user data with encrypted credentials
Redis-backed Bull queue that manages asynchronous workflow execution with retry logic and monitoring
Collection of app definitions loaded at startup that define available triggers, actions, and authentication methods
Feedback Loops
- Webhook retry loop (retry, balancing) — Trigger: Failed webhook delivery or processing error. Action: Bull queue automatically retries failed jobs with exponential backoff. Exit: Maximum retry attempts reached or job succeeds.
- Connection verification loop (polling, balancing) — Trigger: Periodic background job or user-initiated check. Action: System calls isStillVerified() function for each connection to test auth tokens. Exit: Verification complete or connection marked invalid.
Delays
- Queue processing delay (async-processing, ~varies) — Workflows execute asynchronously after trigger, allowing high throughput but adding latency
- OAuth token refresh (cache-ttl, ~token expiry) — Connections periodically re-authenticate when tokens expire, causing brief delays
Control Points
- Request body size limit (threshold) — Controls: Maximum size of webhook payloads and API requests the system will accept. Default: appConfig.requestBodySizeLimit
- Environment variables (env-var) — Controls: Database connections, Redis host, encryption keys, webhook secrets, and protocol settings. Default: POSTGRES_HOST, REDIS_HOST, ENCRYPTION_KEY, etc.
- CORS configuration (feature-flag) — Controls: Which frontend domains can access the API and what methods are allowed. Default: corsOptions
- Enterprise features (architecture-switch) — Controls: Whether AI agent functionality and other enterprise features are available. Default: .ee. file naming convention
Technology Stack
HTTP server framework handling API routes, webhook endpoints, and middleware orchestration
Redis-backed job queue system managing asynchronous workflow execution with retry logic and monitoring
Primary database storing workflows, executions, user data, and encrypted connection credentials
Queue backend for Bull jobs and caching layer for session management
Authentication middleware handling OAuth flows and session management for user login and service connections
Frontend framework providing the visual workflow builder interface and management dashboard
Containerization platform for easy deployment with compose configuration including all dependencies
Error tracking and performance monitoring for production workflow execution
Key Components
- defineApp (factory) — Creates standardized app definitions with authentication, triggers, and actions that integrate external services into the workflow system
packages/backend/src/helpers/define-app.js - defineAction (factory) — Creates action definitions that specify how to execute API calls or operations for external services within workflow steps
packages/backend/src/helpers/define-action.js - createBullBoardHandler (orchestrator) — Sets up Bull queue monitoring dashboard and manages the Redis-backed job queue system for asynchronous workflow execution
packages/backend/src/helpers/create-bull-board-handler.js - configurePassport (adapter) — Configures OAuth and authentication strategies for user login and external service connections using Passport.js middleware
packages/backend/src/helpers/passport.js - runAgent (executor) — Executes AI agents within workflows by processing prompts and returning AI-generated responses as workflow data
packages/backend/src/helpers/agents.js - router (gateway) — Main Express router that handles all HTTP endpoints including webhooks, API routes, and workflow management requests
packages/backend/src/routes/index.js - errorHandler (processor) — Centralized error handling middleware that catches workflow execution errors, logs them, and returns structured error responses
packages/backend/src/helpers/error-handler.js - Agent (store) — Database model for enterprise AI agents that can be executed within workflows to process natural language prompts
packages/backend/src/models/agent.ee.js
Explore the interactive analysis
See the full architecture map, data flow, and code patterns visualization.
Analyze on CodeSeaRelated Repository Repositories
Frequently Asked Questions
What is automatisch used for?
Self-hosted workflow automation platform connecting apps through triggers and actions automatisch/automatisch is a 8-component repository written in JavaScript. Data flows through 5 distinct pipeline stages. The codebase contains 2733 files.
How is automatisch architected?
automatisch is organized into 4 architecture layers: Web Interface, Orchestration Engine, App Integrations, Data Layer. Data flows through 5 distinct pipeline stages. This layered structure keeps concerns separated and modules independent.
How does data flow through automatisch?
Data moves through 5 stages: Receive webhook trigger → Queue workflow execution → Execute workflow steps → Perform external API calls → Store execution results. External services send webhook triggers to the system, which validates the payload, looks up matching workflows, and executes them step-by-step through a Bull queue. Each step authenticates with external services using stored connections, performs the configured action (API call, data transformation, agent execution), and passes the output to the next step until the workflow completes. This pipeline design reflects a complex multi-stage processing system.
What technologies does automatisch use?
The core stack includes Express.js (HTTP server framework handling API routes, webhook endpoints, and middleware orchestration), Bull (Redis-backed job queue system managing asynchronous workflow execution with retry logic and monitoring), PostgreSQL (Primary database storing workflows, executions, user data, and encrypted connection credentials), Redis (Queue backend for Bull jobs and caching layer for session management), Passport.js (Authentication middleware handling OAuth flows and session management for user login and service connections), React (Frontend framework providing the visual workflow builder interface and management dashboard), and 2 more. A focused set of dependencies that keeps the build manageable.
What system dynamics does automatisch have?
automatisch exhibits 3 data pools (Workflow Database, Job Queue), 2 feedback loops, 4 control points, 2 delays. The feedback loops handle retry and polling. These runtime behaviors shape how the system responds to load, failures, and configuration changes.
What design patterns does automatisch use?
4 design patterns detected: Plugin Architecture, Enterprise Edition Segregation, Context Injection, Webhook-First Triggers.
Analyzed on April 20, 2026 by CodeSea. Written by Karolina Sarna.