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.
A production deployment needs a reachable application, persistent records, dependable execution capacity and a recovery path. Size and verify those parts together.

​
Application and public URL

Use the pinned Sydekyks image and AP_EDITION=ce. Set AP_FRONTEND_URL to the HTTPS URL the users and connected providers will use. The URL controls callback and webhook addresses. Verify proxy routes for API, WebSockets and MCP where enabled.

​
Database and queue

Use PostgreSQL and Redis with access restricted to the deployment’s application/worker network. Configure persistence, backup and recovery appropriate to the chosen services. Keep database and queue credentials separate from user app connections.

​
Workers

Workers execute jobs. Choose worker replicas, concurrency and container limits based on the measured workload. The underlying source default for AP_WORKER_CONCURRENCY is 5. For the per-job isolation described in the reserved-resource reference, use concurrency 1 and individually resource-capped worker containers. Concurrency 1 alone does not create CPU or memory reservations; the orchestrator must enforce them. Some gadgets require npm-enabled code or process isolation modes with additional privileges. Choose a supported sandboxing mode deliberately and validate the actual threat boundary.

​
Files and retention

Choose database or S3-compatible storage for step files and larger results. Set retention and pause lifetime together. Preserve business documents and approvals in their intended records system rather than relying only on run logs.

​
Email and integrations

Configure outbound email for account recovery and operational messages. Verify each external provider’s callbacks, credentials and quota. A test using one API key does not verify every installed gadget.

​
Operational acceptance

  • A harmless sample automation completes from its actual trigger.
  • Draft changes, publication and enabled state behave as documented.
  • Logs show enough information to diagnose a failure without exposing credentials.
  • A restarted application/worker retains required state.
  • The backup restores into an isolated environment with the same encryption key.
  • Resource, timeout and retry behavior match the intended workload.
  • The operator and support owner can respond to a failed trigger or queue backlog.
Record the deployed revision and configuration alongside the acceptance results. Use observability for the supported operational telemetry paths.