This is an upstream technical reference retained from the pinned documentation revision. Its diagrams, timings and implementation details are not measurements or release guarantees for Sydekyks. Validate differences against the selected fork release before using it operationally.
This section explains why Sydekyks works the way it does: the components, the execution model, and the trade-offs behind them. If you want to do something (size a deployment, set up SSL, scale workers), start with Configure & Operate. Come here when you want the reasoning under those choices. This page describes the main components, with a focus on how flows run.

​
Components

Workflow architecture: client, app, Redis job queue, PostgreSQL, configured file storage and workers Sydekyks:
  • App: The main application that organizes everything from APIs to scheduled jobs.
  • Worker: Polls for new jobs, allocates a sandbox from the pool, executes the flows with the engine inside the sandbox, and sends results back to the app.
  • Sandbox: An isolated execution environment that manages process lifecycle, resource limits, and communication with the engine via WebSocket.
  • Engine: TypeScript code that parses flow JSON and executes it. It is compiled into a single JS file and runs inside the sandbox.
  • UI: Frontend written in React.
Third Party:
  • Postgres: The main database for Sydekyks.
  • Redis: Powers the queue using BullMQ.

​
Reliability & Scalability

Postgres and Redis availability is outside the scope of this documentation, as many cloud providers already implement best practices to ensure their availability.
Everything is queue-backed: webhooks and recurring jobs land on Redis, and workers poll them off it. A spike does not drop work. It queues and drains as slots free. For exactly what survives a crash, what runs at-least-once, and where each promise stops, see Guarantees. To scale Sydekyks, add replicas of the workers, the app, or the Postgres database. A small Redis instance is enough: it handles thousands of jobs per second and rarely becomes a bottleneck. For the concrete sizing model, see Production Setup.

​
Repository Structure

The repository is a monorepo built with Turbo, with TypeScript as the primary language. It is divided into several packages:
  • web: This package contains the user interface, implemented using the React framework.
  • api: This package contains the main application written in TypeScript with the Fastify framework.
  • worker: This package contains the logic of accepting flow jobs and executing them using the engine.
  • server-sandbox: This package contains the sandbox execution environment, including process isolation, pool management, and WebSocket communication between the worker and engine.
  • common: This package contains the shared logic between worker and app.
  • engine: This package contains the logic for flow execution within the sandbox. Located under server/engine.
  • pieces: This package contains the implementation of triggers and actions for third-party apps.
  • shared: This package contains shared data models and helper functions used by the other packages.
  • ee: This package contains features that are only available in the paid edition.