chat-sdk-deploy-bot: A Slack bot that treats deployment like a control plane
Vercel Labs' template keeps humans in the loop, pushes the waiting into a durable workflow, and fans the result back out to GitHub and Linear.
- The bot treats deployment as a control-plane problem, not a chat integration problem.
- Vercel Workflow carries the waiting state so approval and polling do not depend on fragile serverless timers.
- Chat SDK lets one TypeScript code path render the same deploy intent across Slack, GitHub, and Linear.
- The repository is written like a template for both humans and agents, with `.agents` and `.claude` folders that explain how to extend it.
Most deployment bots are just slash commands with a memory problem. This one is closer to a control room. Slack collects the decision, Vercel Workflow holds the state, and GitHub Actions does the build. The point is not to chat about deploys. It is to keep the approval, the wait, and the aftermath in one loop.
A deploy bot with a wider job than chat
Vercel Labs built chat-sdk-deploy-bot as a template around Chat SDK and Vercel Workflow. The README describes it plainly: trigger deploys from Slack, gate production with approval, dispatch GitHub Actions, and notify GitHub and Linear when the run finishes. That matters because most teams still stitch those steps together with brittle scripts, webhooks, and polling jobs.
A deploy orchestrator built with Chat SDK and Vercel Workflow. Trigger deploys from Slack, gate production with approval, dispatch GitHub Actions, and notify GitHub and Linear when the run finishes.
Why the abstraction matters
The interesting part is not the chat surface itself. Plenty of tools can post a message. The interesting part is the shape of the app. A deployment is modeled as a long-lived transaction, and the chat platform is just the front door. That is why the same core logic can survive across platforms without turning into a nest of if statements.
Vercel shipped the Chat SDK on February 23 - a TypeScript library that claims to solve one of the most tedious problems in chatbot development: writing the same bot logic six times for six different platforms.
- Approval starts in Slack.
- The webhook route hands the event to the shared bot registry.
- A durable workflow pauses at the approval hook and resumes later.
- GitHub Actions runs, then Slack, GitHub, and Linear get the result.
How the workflow survives the wait
The dynamic route at app/api/webhooks/[platform]/route.ts normalizes Slack, GitHub, and Linear into one entry point. It uses after() to return quickly, then pushes the heavy lifting into background work. Inside workflows/deploy-workflow.ts, use step and createHook let the run pause for a human click without keeping a serverless function open for an hour.
The GitHub adapter adds a small but telling bit of resilience. If the target Action does not accept the deploy_id input, it retries with slimmer payloads. That is the kind of defensive code that turns a demo into an operational tool.
Where it sits in the landscape
| Approach | Strength | Constraint | Why this repo is different |
|---|---|---|---|
| Slack Bolt | Great Slack-first bot ergonomics | Another channel usually means another implementation | Chat SDK aims to keep one core flow across platforms |
| GitHub Actions slash commands | Natural for repo-centric teams | Weak approval UI and limited cross-platform reach | This repo pulls chat, workflow, and follow-up into one loop |
| Hubot-style ChatOps | Flexible and familiar scripting model | State, retries, and long waits are on you | Durable Workflow handles the waiting instead of ad hoc polling |
| chat-sdk-deploy-bot | One TypeScript flow for chat and deploy state | Still a template, not a finished product | That is the point, it shows the abstraction before the polish |
The .agents and .claude directories push the same idea one step further. The repo is documented as if an assistant will need to extend it, not just a human maintainer. That is a small signal, but it points to where open source infrastructure is heading: codebases written to be read, changed, and recomposed by people and tools alike.