Security and recovery

Exposure model

Workflow webhook execution endpoints require Authorization: Bearer <key> using the fixed environment-defined APPLICATION_API_KEY. Channel integration and runner APIs keep their separate bearer-token authentication, and channel callbacks keep HMAC signature validation.

Keep services behind trusted network boundaries. Use TLS at ingress whenever API keys, runner tokens, or channel secrets leave a private development network.

Trusted inputs

Only trusted people may edit workflow YAML, scripts, expressions, mounted channel drivers, or MCP definitions. Restrict HTTP node destinations with host policy and keep credentials in secret stores/environment variables. Runner requests contain sensitive material and require private networking or TLS.

Backups

Back up these sets atomically while their service is stopped or by using SQLite-safe backup tooling:

• RUN_DATA_DIR, including runs.sqlite, server-config.sqlite, the configured CHANNEL_DATA_FILE, and the generated workspace-driver dependency cache. server-config.sqlite contains authorization grants but not API key secrets.
• CHANNEL_DATA_DIR and any writable paths used by memory drivers or workflow scripts when they are outside RUN_DATA_DIR.
• Workflow packages and the deployed application version.
• The exact CHANNEL_SECRET_KEY, APPLICATION_API_KEY, and other external secret material in a separate secret manager.

Losing CHANNEL_SECRET_KEY makes encrypted channel credentials unreadable. Restoring database files without matching workflows, drivers, and configuration can leave resumable checkpoints or channel instances incompatible with the deployed application.

Retention and deletion

Terminal runs expire according to ASYNC_RUN_RETENTION_DAYS; persistent workflow values are intentionally not removed by run retention. Callback metadata may retain destination and error information until its run expires. Establish a separate data policy for workflow inputs and outputs, which may contain business data.