The Forgotten Protagonist of App Distribution — and How AI Agents Finally Put Them Back in Focus
Today, we are releasing the DeployGate Agent Plugin — a Claude Code/Codex plugin that lets you set up DeployGate end-to-end by talking to an AI agent instead of clicking through a dashboard. Two slash commands install it; from there, your agent handles sign-in, the first upload, Slack/Teams/Chatwork notifications, per-pull-request distribution pages, and the Android SDK.
Why we built it has less to do with developer convenience than it might look.
The real protagonist has always been the tester
Most stories about pre-release app distribution are told from the developer’s chair: “I built it, I uploaded it, I sent the link.” But the protagonist of that story has never been the developer. It is the tester — and “tester” here is broader than the public-beta sign-up the word sometimes implies. It is the in-house QA engineer running a release-candidate checklist, the partner-agency QA team verifying a client deliverable, the product manager spot-checking the latest build, the designer signing off on a UI change. The people who install your build, run through the scenarios, find the rough edges, and tell you about them.
Whether a testing cycle produces useful feedback is decided entirely by what happens after “the build is uploaded.” Can your tester install without friction? Can they find the right build at the right time? Can they capture the bug they just hit and tell you about it without having to write a paragraph of context?
DeployGate has been built around this premise since 2012. It is, deliberately, not a public-beta funnel — it is a tool for getting pre-release builds in front of QA testers (internal and external) and other stakeholders, with as little friction as possible.
What a fully-configured DeployGate gives your testers
When DeployGate is set up the way it is meant to be, every person in the list above gets something specific:
- The partner-agency QA team gets a per-pull-request distribution page with a QR code posted directly to the PR. They install the candidate build by scanning, no account creation and no app-store dance, and the page is torn down automatically when the PR closes.
- Your in-house QA engineer gets in-device screen capture and replay. A bug report becomes a tap — a video of what just happened, with the device context attached — instead of a paragraph of writeup.
- The product manager gets Instant Device: they verify the latest build from a browser, without owning the target hardware and without taking up tester bandwidth.
- The designer signing off on a UI change gets the same Instant Device path, plus a Slack/Teams/Chatwork channel that announces every new build automatically, so “did you push that fix yet?” stops being a question anyone has to ask.
These are not new features. They are the features DeployGate has been shipping for over thirteen years. The thing that has changed is whether teams actually have them turned on.
The “set up == done” trap
There is a pattern we have watched play out for years across our users.
Your team ships its first DeployGate build. The link works. A tester installs it. Everyone exhales. The session ends with a quiet ”okay, that was easy.”
And then nothing else gets configured.
The Slack integration that would have routed every upload, install, and bug report into your team channel — never enabled. The Instant Device option that would have let your PM check the latest build from a browser — never turned on. The per-pull-request distribution page that would have given reviewers a QR code on every PR — never wired up. The Android SDK that powers in-device capture — never added.
Get Yuki Fujisaki (rai)’s stories in your inbox
Join Medium for free to get updates from this writer.
These are the features that move a team from ”I shipped a build” to ”my testers can do their job.” But “the first build worked” tends to be the same moment teams disengage from the tooling. The remaining setup never happens, and a meaningful chunk of your tester experience gets quietly left on the table. Better docs, onboarding emails, and dashboard nudges all helped at the margins; none of them changed the underlying fact that more tooling configuration is exactly the work engineers are most willing to defer.
A new interface for setup
What changed in the last year is the interface through which your team interacts with its tooling.
It is now routine to ask an AI agent — Claude Code, Codex, Cursor, Devin, GitHub Copilot — how to integrate a service into your project. Setup is increasingly something you delegate, not something you read a guide about. ”Wire DeployGate uploads into our GitHub Actions” or ”post the latest QA build to our Slack channel” is a sentence you type to your editor, not a checklist you keep open in another tab.
If that is how setup works now, then the right form factor for a distribution platform is no longer a long documentation page. It is a tool the agent itself can drive on your behalf — end to end, with the integrations that benefit your testers wired up by default rather than buried under “you can also enable this later.”
The DeployGate Agent Plugin
Two commands install the plugin into any Claude Code session:
/plugin marketplace add DeployGate/deploygate-agent-plugin
/plugin install deploygate@deploygate-marketplaceThere is no Node.js to install and no API token to paste. The plugin runs as a self-contained MCP server, and authentication is a one-tap browser approval (a device authorization code flow) that persists across future sessions.
From there, your agent can drive four high-level workflows: /deploygate:setup walks through sign-in, the first upload, distribution pages, chat notifications, and (for iOS) tester device registration. /deploygate:deploy is the day-to-day “ship a new build” command, detecting your toolchain and writing a useful upload message from the current branch and commit. /deploygate:ci-setup generates a GitHub Actions / Bitrise / CircleCI / Codemagic workflow, including the per-PR distribution template that gives reviewers a QR-coded PR comment. /deploygate:sdk-setup adds the Android SDK with a debug/release split. Full reference is in the documentation.
The point that matters is not the command list. It is that the integrations we have historically watched teams skip — Slack notifications, per-PR distribution pages, the SDK — are no longer optional pages to discover separately. They are first-class branches of the conversation your agent walks you through during initial setup. The path of least resistance now leads toward the configuration that benefits your testers, not around it.
Built openly, included in every plan
The plugin is open source, MCP-native, and uses the same DeployGate accounts and APIs that power the rest of the platform. There is no separate plan tier — every DeployGate plan, including the Free plan, can use it at no extra cost. We chose MCP over a thin API wrapper deliberately: it means the same plugin model extends to other agents (Codex, Cursor, and beyond) as their plugin ecosystems mature, and it means your team is not locked into a single editor to drive its release workflow.
- Repository: https://github.com/DeployGate/deploygate-agent-plugin
- Documentation: https://docs.deploygate.com/docs/developer-tools/agent-plugin
Issues and pull requests are welcome on the repository, as is feedback on X with #deploygate.
If you have been distributing builds but never quite got to the rest
Your job is not to “ship a build”; it is to put your testers in a position to give you great feedback. The piece that has always been missing was a way to turn the relevant DeployGate features on without asking you to spend time you would rather spend elsewhere. If that has been your team’s story, this is the moment it becomes a one-command problem. In Claude Code:
/plugin marketplace add DeployGate/deploygate-agent-plugin
/plugin install deploygate@deploygate-marketplaceThen /deploygate:setup, and let your agent do the rest.
