Orchestration and state: tying Slack, Claude Code, GitHub, and Synology together

Decision. GitHub Actions is already running Claude Code [27] ⭐ 7.3k, so make Actions the orchestrator and stash correlation state in one small key-value store keyed by Slack thread_ts (Redis, SQLite, or Cloudflare Durable Object [16]). Reach for a durable-execution engine — DBOS [7] ⭐ 1.2k for Postgres-only shops, Cloudflare Workflows [14] for Workers shops, Temporal [4] ⭐ 20k only when the flow truly needs step.waitForEvent semantics, multi-day pauses, or fan-out beyond what Actions matrix gives you. For this pipeline (Slack → Claude → PR → Synology preview), the lightweight path wins — Claude Code’s GHA jobs themselves cap at 6 h [17], and the human approval gate is a Slack button + repository_dispatch, not a multi-day suspended workflow.

What state is actually moving

Before picking an orchestrator, name the bytes. Across this pipeline four kinds of state need to survive between steps:

The first two need a small persistent store; the third is ephemeral and lives in the runner; the fourth uses GitHub Actions artifacts or GHCR. Every claim in the rest of this doc rolls up to one of these four.

Two orchestrator shapes

Shape A — GitHub Actions as the orchestrator

The default. The trigger graph already exists: repository_dispatch from Slack → claude-code-action job [27] → peter-evans/create-pull-request step → pull_request event → preview-deploy workflow → status-back-to-Slack step. State that has to outlive a single job goes into one external KV; everything else flows as job outputs and artifacts.

Within Actions’s native budget. Job outputs cap at 1 MB per job, 50 MB per run [19] and reusable workflows can chain 10 deep [18] — fine for IDs and URLs, hopeless for diffs. Anything bigger goes to artifacts. Secrets do not auto-propagate down a workflow_call chain — pass each one explicitly [18]. A workflow run can total 35 days including approval waits [17], but a single job is still capped at 6 h hosted / 5 d self-hosted.

The KV store. Pick one of three by team’s existing infra:

Slack Bolt itself ships no durable state [22] ⭐ 2.9k — token storage, modal state, and per-thread leases are the developer’s problem. That’s the gap the KV fills.

Shape B — A durable-execution engine

Worth it when the flow needs to pause for hours, retry across process restarts, or fan out beyond the Actions matrix. The shape: the Slack bot starts a workflow; each step (call Claude Code, open PR, build preview, await approval, promote) is a checkpoint; if the worker crashes, the engine replays from the last successful step. Every option below saves the result of every completed step so retries skip them [1].

Decision shortcut. If the team already has Postgres → DBOS or Hatchet. Already on Workers → Cloudflare Workflows. Already polyglot at scale → Temporal. Already TypeScript-everywhere → Trigger.dev. None of those describe a Slack→Claude→PR pipeline that runs in single-digit minutes — which is why Shape A wins for this specific pipeline.

Where the patterns differ on human-in-the-loop

The “wait for the reviewer to click Approve” gate is the one place a durable-execution engine is qualitatively better than Actions. Compare:

For a homelab pipeline where the reviewer is one of two humans and replies in minutes, the Actions+KV path is the simplest correct thing. For a regulated org where the reviewer might be on PTO, durable-execution earns its complexity tax.

State store cookbook for the lightweight path

KEY                                        VALUE (json)
slack:thread:{thread_ts}                   { team_id, user_id, repo, branch, run_id, pr_number, preview_url, status }
slack:lock:{thread_ts}                     "<worker-id>"          (TTL 15s, lease for processing) [[21]](https://redis.io/tutorials/chat-sdk-slackbot-distributed-locking/)
approval:{pr_number}                       { state: "pending"|"approved"|"rejected", approver, ts }
run:{run_id} → {thread_ts}                 reverse index for callbacks from Actions

Two endpoints close the loop: a Slack button handler that flips approval:* and emits repository_dispatch, and a workflow_run listener that reads run:* and posts to Slack. Every other piece of state stays inside one Actions run.

Pitfalls

• Don’t use Actions outputs for diffs. 1 MB cap [19] — push diffs as artifacts and link from the PR comment.
• Slack thread_ts is your only stable correlation key before a PR exists. Generate it client-side and pass it through every dispatch payload.
• Default GITHUB_TOKEN doesn’t trigger downstream workflows. Use a GitHub App installation token to push the branch, otherwise the preview deploy never runs.
• Don’t pick Temporal for a flow whose longest wait is a Slack approval. The 50K-event / 50 MB-history cap [20] is generous, but the operational tax is real and the human gate fits a row in a table [26].
• Don’t double-process Slack events. Slack retries within 3 s if no 200; a Redis lease keyed on thread_ts is one line and prevents two runners from racing on the same task [21].
• DEEs and event logs are complements, not substitutes. If Kafka is already in the stack, the engine handles the workflow lifecycle on top of the event log [28].