Skip to content

Deploy Approval & Release Notes · Developer

Ship with release notes, a risk check and a human OK every time

When a build is ready, it writes release notes, rates the risk with a rollback plan and asks for approval in Slack. Only after a person approves does it trigger your deploy.

Available now $79 one-time · never renewsIncluded in Enterprise

Free account to start. Buying and running live need a paid plan.

  • Starts when your form or app sends it something
  • 1 AI step
  • A person approves before it acts
  • About 30 min to set up

Sound familiar?

The job, before and after this agent.

What it feels like today

  • “Release notes are written in a rush after the deploy, if at all.”
  • “Risky changes like migrations go out on a Friday without anyone noticing.”
  • “When a deploy fails, on-call starts from a wall of logs.”

What you get with the agent

  • Internal and customer-facing release notes written from the commits.
  • A risk rating with reasons (migrations, auth, payments, config, dependency bumps, your sensitive areas), a freeze-window check and a rollback plan.
  • Approval requested in Slack; the deploy request is sent only after a person approves in Reviews.
  • Release notes shared in Slack once your deploy endpoint accepts the request.
  • Failed deploys sent to on-call with the failing log line, a likely cause framed as a hypothesis and next steps.

Before

Someone merges a database migration late on Friday, deploys by habit, and the release notes are a commit list pasted into chat. When it fails, on-call scrolls logs for twenty minutes.

After

The build lands in #releases with notes, a high-risk flag for the migration, a rollback plan and a freeze-window warning. A lead approves on Monday morning. If a deploy fails, on-call gets the failing line and next steps.

How it works

The whole workflow, step by step.

Your CI (GitHub Actions, GitLab CI, CircleCI…) posts to the agent's webhook when a build is ready for production or a deploy failed. 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 and freeze windows) with reasons and a rollback plan, and asks for approval in Slack. Only after a person approves 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 in Slack. Failed deploys and blocked builds go to your on-call channel with the failing log line, a likely cause and next steps. It never deploys or rolls back on its own, and doesn't update status pages, changelogs or DORA metrics.

  1. TriggerBuild ready or deploy failed
  2. AI stepWrite release notes and assess risk
  3. LogicFailed, blocked or ready?
    • Failed or blocked:Alert on-call in Slack
    • Ready:Ask for deploy approval in Slack
    • Ready:Approve the production deploy
  4. App callAlert on-call in Slack
  5. OutputOn-call alerted
  6. App callAsk for deploy approval in Slack
  7. OutputApproval requested
  8. Human approvalApprove the production deploy
    • Approved:Send the deploy request
    • Rejected:Not deployed
  9. App callSend the deploy request
  10. OutputDeploy requested
  11. App callShare the release notes
  12. OutputRelease notes shared
  13. OutputNot deployed

This is the workflow that opens in your workspace when you set the agent up. Every step can be edited.

  1. Step 1Build ready or deploy failedYour 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).
  2. Step 2Write release notes and assess riskAI 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.
  3. Step 3Failed, blocked or ready?Failed deploys and blocked builds page your on-call channel; builds ready for production go to a person for approval.
  4. Step 4Alert on-call in SlackPosts the failure diagnosis and next steps (or why the build is blocked) to your on-call channel with a link to the CI run.
  5. Step 5On-call alertedThe run history keeps the diagnosis.
  6. Step 6Ask for deploy approval in SlackPosts the risk, release notes and rollback plan to your release channel and asks an approver to open Reviews.
  7. Step 7Approval requestedThe run history keeps the request.
  8. Step 8Approve the production deployA person checks the risk, release notes and rollback plan in Reviews, then approves to send the deploy request, or rejects to stop it.
  9. Step 9Send the deploy requestCalls your deploy endpoint with your token (by default GitHub's “run workflow” API for your deploy workflow on the approved ref).
  10. Step 10Deploy requestedThe run history keeps your pipeline's response.
  11. Step 11Share the release notesOnce your deploy endpoint has accepted the request, posts the approved release's customer-facing and internal notes to your release channel.
  12. Step 12Release notes sharedThe run history keeps the release notes.
  13. Step 13Not deployedThe reviewer rejected the deploy; nothing was sent to your pipeline.

Example run

What goes in, and what comes out.

Example with fictional data

Comes in

Fictional ready_to_deploy event for a sample web app: 4 commits including a new invoices index migration and a framework patch bump; checks passed.

The agent produces

Release notes (internal and customer-facing), risk Medium: migration on a large table, dependency bump; rollback plan to the previous commit. Waiting for approval in Slack; after approval, deploy workflow triggered and notes posted.

What you need

Everything it takes to run it.

About 30 minutes from purchase to live. A checklist above the canvas takes you through each step.

Plan

Included in Enterprise; on other paid plans it's $79 once. Agents run live on paid plans, from Basic ($39/mo).

Your AI key

Connect any of 14 AI providers on your own key. Your provider bills usage directly, at cost; we add no markup.

Checklist

  • 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).

Setup, about 30 minutes

  1. Connect your AI provider. The AI steps run on your own key (OpenAI, Anthropic, Google and more). Add one in Settings → AI Providers.
  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”.
  3. Connect Slack. Connect the Slack workspace your engineers use (Settings → Integrations → 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.
  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.

Is it a fit?

Who it's for, and what it won't do.

Built for

  • Small engineering teams without a release manager
  • Startups wanting a documented approval before production
  • Tech leads and CTOs
  • Agencies deploying client apps

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.

We list the limits up front so you can decide before you buy.

Price

$79 one-time

Per workspace. It never renews.

Available now
  • Included at no extra cost on Enterprise.
  • Buying and running it live need a paid plan, from Basic ($39/mo).
  • Dry Run costs nothing: simulated AI and app calls, nothing sent.
  • AI usage is billed by your own provider, at cost. No AI credits to buy from us.

One-time agent purchases aren't covered by the 30-day money-back guarantee. Refund policy

FAQ

Questions about Deploy Approval & Release Notes.

Could it deploy something on its own?

No. A ready build always waits in Reviews, and the deploy request is sent only when a person approves. It never rolls back by itself.

Does it work with my CI?

Yes, if your CI can POST two events (ready to deploy, deploy failed) to its webhook: GitHub Actions, GitLab CI, CircleCI and others. By default it triggers a GitHub Actions workflow; Vercel or Netlify build hooks also work.

How long is setup?

About 30 minutes: add the CI steps, create an HTTP connection to your deploy API with a token, connect Slack and describe your services and release policy. To run it live you need a paid plan and your own AI provider key (OpenAI, Anthropic, Google and others), added in Settings. Dry Run on sample data is free, so you can see real output before you commit.

Is it worth the price?

It's a one-time purchase that never renews. One bad Friday deploy avoided, or one faster recovery, covers it.

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.

Is this a subscription?

No. Deploy Approval & Release Notes is a one-time purchase of $79 per workspace and never renews. The Enterprise plan includes it at no extra cost. Running it live needs a paid plan (from Basic ($39/mo)), and your AI provider bills you directly for usage.

Can I test it before it touches real data?

Yes. Once it's set up in your workspace, Dry Run plays every step on sample data with simulated AI and app calls: nothing is sent and nothing in your apps changes. Switch the trigger on only when you're happy.

Put Deploy Approval & Release Notes to work.

Free account, no credit card. Your Agents page opens with Deploy Approval & Release Notes ready to buy and set up, then Dry Run it before it goes live.