Deploy Approval & Release Notes

What it does

Release notes and a risk check for every production build, a human approval, then your deploy is triggered.

• Receives events from your CI through a webhook: a build that passed and is ready for production, or a deploy that failed (with the end of its log).
• For a ready build, AI writes internal and customer-facing release notes from the commits, rates the risk (migrations, auth, payments, config, dependency bumps, your sensitive areas) with reasons and a rollback plan, and checks your freeze windows.
• Posts the deploy for approval to your Slack releases channel. Only when a person approves it in Reviews does it send the deploy request to your endpoint (by default GitHub's run-workflow API) with your token, and, once your endpoint accepts the request, share the release notes.
• Failed deploys and blocked builds go to your on-call channel with the failing log line, a likely cause framed as a hypothesis, next steps and the rollback target.
• Every event, approval and response is kept in the run history.

What it needs

• A paid plan (agents run live on paid plans).
• An AI provider key (Settings → AI Providers).
• Slack, and an HTTP / Custom API connection to the API that starts your deploys (e.g. GitHub with a token that can run workflows).
• CI steps that POST ready_to_deploy and deploy_failed events to the webhook (fields listed in the FAQ).

What it doesn't do

• It never deploys without a person approving in Reviews, and doesn't roll back by itself.
• It doesn't watch CI on its own or connect to GitHub, GitLab or CircleCI as an app: your CI sends the events.
• It doesn't check whether the deploy succeeded after the request; your pipeline reports failures back as deploy_failed events.
• It doesn't post to status pages or Discord, update a changelog file, or track DORA metrics.

Availability and plans

Included free on the Enterprise plan; on other paid plans it's a one-time purchase per workspace (the price is on the Agents page). The Agents page in the app always shows its current status.

Before you start

• A paid plan: agents run live, and the Free plan only runs Dry Runs.
• An AI provider key (OpenAI, Anthropic, Google and more) in Settings → AI Providers. AI usage is billed by your provider.
• These apps, connected in Settings → Integrations: HTTP / Custom API and Slack.
• A form, app or system that can send each new item to a webhook URL (the agent starts from a webhook).
• About 30 minutes.

• Bring your own AI key
• HTTP / Custom API (live)
• Slack (live)

Set it up step by step

Get the agent first (buy it, or it's already yours when your plan includes it), then in Agents → My agents press “Set up this agent”. That creates the agent's workflow in your workspace (it counts towards your plan's workflow limit) and opens the canvas with a setup checklist above it. Each item links to the exact place to go and ticks itself off when it's done.

1. Connect your AI provider

The AI steps run on your own key (OpenAI, Anthropic, Google and more). Add one in Settings → AI Providers.

• Connect your AI provider

2. Connect your deploy API (HTTP / Custom API)

In Settings → Integrations, add an HTTP / Custom API connection for the API that starts your deploys, e.g. base URL https://api.github.com, Authentication “Bearer token”, and a fine-grained token for the repository with “Actions: Read and write”.

• Connecting HTTP / Custom API

3. Connect Slack

Connect the Slack workspace your engineers use (Settings → Integrations → Slack).

• Connecting Slack

4. Describe your release policy

Open “Write release notes and assess risk” and replace the placeholder with your services, sensitive areas and freeze windows.

5. Point it at your deploy

Open “Send the deploy request”, pick your deploy API connection and replace OWNER, REPO and the workflow file in the path (or enter your deploy hook's path).

6. Pick the Slack channels

Open the three Slack steps and pick your account and a channel in each (on-call, approvals, release notes). Invite the app to private channels first (/invite @Fluxo Flow).

7. Test it with Dry Run

Press Dry Run: the agent runs on sample data with no messages sent and nothing written to your apps.

• Dry Run vs Run

8. Switch the trigger on

Switch the webhook on and add two CI steps that POST to its URL with the x-fluxo-secret header: one after tests pass on your release branch (event ready_to_deploy) and one when a deploy job fails (event deploy_failed). The fields are in the agent's FAQ.

How it works

The agent is a normal workflow with 13 steps (1 AI step, with a person approving in Reviews). You can open, edit and monitor it like any other workflow.

• Build ready or deploy failed — Starts when your form or app sends data to the agent's webhook URL. Your CI posts to the workflow's webhook URL when a build has passed and is ready for production (event ready_to_deploy), or when a deploy failed (event deploy_failed, with the end of the log).
• Write release notes and assess risk — AI step (runs on your AI provider key). AI writes internal and customer-facing release notes from the commits, rates the deploy's risk with reasons and a rollback plan, or diagnoses a failed deploy from its log.
• Failed, blocked or ready? — Decision: picks the branch to follow. Failed deploys and blocked builds page your on-call channel; builds ready for production go to a person for approval.
• Alert on-call in Slack — Slack: Post a message. Branch: Failed or blocked. Posts the failure diagnosis and next steps (or why the build is blocked) to your on-call channel with a link to the CI run.
• On-call alerted — Kept in the run history. The run history keeps the diagnosis.
• Ask for deploy approval in Slack — Slack: Post a message. Branch: Ready. Posts the risk, release notes and rollback plan to your release channel and asks an approver to open Reviews.
• Approval requested — Kept in the run history. The run history keeps the request.
• Approve the production deploy — A person approves or rejects it in Reviews (the run waits). Branch: Ready. A person checks the risk, release notes and rollback plan in Reviews, then approves to send the deploy request, or rejects to stop it.
• Send the deploy request — HTTP / Custom API: Send a request. Branch: Approved. Calls your deploy endpoint with your token (by default GitHub's “run workflow” API for your deploy workflow on the approved ref).
• Deploy requested — Kept in the run history. The run history keeps your pipeline's response.
• Share the release notes — Slack: Post a message. Once your deploy endpoint has accepted the request, posts the approved release's customer-facing and internal notes to your release channel.
• Release notes shared — Kept in the run history. The run history keeps the release notes.
• Not deployed — Kept in the run history. Branch: Rejected. The reviewer rejected the deploy; nothing was sent to your pipeline.

Test it with Dry Run

Press Dry Run in the canvas. The agent runs on the sample data stored on its trigger (the “Sample data for Dry Run” box), so you can check every step's output before anything is live. Edit the sample to match the fields your own form or app sends.

Sample data fields

event, service, environment, ref, commit_sha, previous_sha, commits, changed_files, checks, ci_url, triggered_by.

• Nothing is sent or written: app actions, emails and Slack posts are simulated, and AI steps don't call your AI provider.
• Approval steps use the Dry Run decision you pick in the step's settings (approved, rejected or timeout), so you can try each branch.

Go live

• Switch the webhook on and add two CI steps that POST to its URL with the x-fluxo-secret header: one after tests pass on your release branch (event ready_to_deploy) and one when a deploy job fails (event deploy_failed). The fields are in the agent's FAQ.
• The webhook is protected by a secret: send it in the header shown in the Activation panel (requests without it are refused with 403). Each request starts one run.
• The setup checklist adds a “paid plan” item before activation: live runs need a paid plan (the Free plan only runs Dry Runs).
• When every checklist item is done and the trigger is on, the checklist says “Live — this agent is running”. Follow its runs in the workflow's History tab and in Analytics → Agents.

• Webhook triggers
• Switching a trigger on (Activation)

Questions

Does it deploy without a person?

No. A build ready for production always waits in Reviews; the deploy request is sent only when someone approves it.

What does my CI need to send?

A JSON POST to the webhook URL with the header x-fluxo-secret: event (ready_to_deploy or deploy_failed), service, environment, ref, commit_sha, previous_sha, commits (e.g. the output of git log --oneline previous_sha..commit_sha), changed_files (git diff --stat), checks (passed or failed), ci_url, triggered_by, and for failures log_tail (the last ~150 log lines).

Which deploy endpoints work?

Any HTTPS API your connection's token can call. The default path starts a GitHub Actions workflow (workflow_dispatch) on the approved ref; it runs on that branch's latest commit. For Vercel or Netlify build hooks, use the hook's host as the connection's base URL and its path here; query parameters go in the step's Query parameters field.

Troubleshooting

• “No AI provider connected” or a rejected key: connect or fix the key in Settings → AI Providers, then press Test there.
• A checklist item stays unticked: the setting is still empty or still contains its placeholder text. Open the step from the checklist and fill it in.
• An app step fails with “Needs reconnect”: the account's access was revoked or expired. Reconnect it in Settings → Integrations.
• Slack says the app isn't in the channel: in Slack, type /invite @Fluxo Flow in that channel (always needed for private channels).
• Nothing happens when your form sends data: check the webhook is switched on and the request carries the secret header (403 means it's missing or wrong).
• A run shows as paused: it's waiting for someone in Reviews to approve or reject it.
• A step failed: open the run in History and check that step in the Trace tab for the error and what it received.

• Debugging failed runs
• Error messages
• Get help