Skip to main content

Slash Commands Reference

Each deploygate:* command is a high-level workflow that the agent drives end-to-end. This page is a quick reference for when to use each command, what it does, and what you get back. You don't need to memorize the steps — the agent will ask you before any decision.

In Claude Code, invoke a command as /deploygate:<name>; in Codex, use $deploygate:<name>. This page uses Claude Code's /deploygate:* form throughout.

If this is your first time, start with Getting Started rather than this page.

/deploygate:setup​

The recommended starting point for first-time users. A single guided flow that takes you from "I have an account, maybe" to "my testers can install the build."

Reach for it when:

  • You've never uploaded to DeployGate before
  • You need to create or reconfigure a distribution page
  • An iOS build is failing with a code-signing or provisioning-profile error
  • A tester reports they can't install your iOS Ad Hoc / Development build
  • You want to send upload notifications to Slack, Microsoft Teams, or Chatwork

What you get: a signed-in plugin, an uploaded build, a shareable distribution URL of the form https://deploygate.com/distributions/{key}, and (optionally) notifications wired up to your team chat.

The flow is:

  1. Sign up / sign in — opens a browser-based approval. The login persists for future sessions.
  2. Upload your app — builds the project and uploads it. For iOS, it can also produce a simulator build so you can preview in the browser via Instant Device.
  3. Create a distribution page — pick an intent (Development / QA / Beta) and get a public URL to share.
  4. Connect notifications — opens the notification settings page in your browser for Slack / Teams / Chatwork.
  5. Register iOS testers (iOS only) — if some testers' devices aren't yet on your provisioning profile, the command collects their device IDs, regenerates the profile, rebuilds, and re-uploads to the same distribution page.

After the basics are in place, the command points you toward CI setup, the Android SDK, and inviting teammates.

/deploygate:deploy​

The fast-path command for projects already set up. Use this for your day-to-day "ship a new build" loop.

What it does, on your behalf:

  • Detects whether your project is Android or iOS
  • Builds the app with the appropriate toolchain
  • Generates a useful upload message from your current Git branch and commit
  • Uploads the build and prints the new revision URL

Options (pass inline after the command):

SyntaxEffect
/deploygate:deploy to "Beta"Target the distribution page named Beta
/deploygate:deploy to key:abc123def456Target the distribution page with that access key
/deploygate:deploy with message "hotfix build"Override the auto-generated upload message

If something blocks the upload (you're not signed in, iOS code signing failed, a tester's device isn't registered), the command hands off to /deploygate:setup, which owns the recovery flows.

note

Do not feed APKs produced by Android Studio's Instant Run / Apply Changes — those are incomplete builds. Always use a full Gradle build.

/deploygate:ci-setup​

Generate CI/CD workflows for automated upload and per-PR distribution.

The command detects your CI from these files:

File presentProvider
.github/workflows/GitHub Actions (with bundled templates)
bitrise.ymlBitrise (uses the official DeployGate step)
.circleci/config.ymlCircleCI
codemagic.yamlCodemagic
noneGitHub Actions is recommended for new setups

What it produces (GitHub Actions): one or both of the bundled templates installed under .github/workflows/ — see GitHub Actions Templates:

The command also walks you through configuring the required repository secrets, recommending a project API key rather than a personal one so the workflow doesn't break when teammates change.

For Android projects already using gradle-deploygate-plugin, it can wire up the combined ./gradlew uploadDeployGateDebug task in place of the separate build + upload steps.

/deploygate:sdk-setup​

Add the DeployGate SDK to an Android app for crash reporting, remote logging, and screen-capture bug reports.

Use this after you've uploaded your app at least once via /deploygate:setup — SDK features only activate when the app is installed via DeployGate, not when run directly from Android Studio.

What the command sets up:

  • A debug/release split so release builds contain no SDK code:

    dependencies {
        debugImplementation("com.deploygate:sdk:4.9.0")
        releaseImplementation("com.deploygate:sdk-mock:4.9.0")
    }

  • For most apps, no initialization code is needed. Multi-process apps get a single line added to Application.onCreate().

  • Optionally, gradle-deploygate-plugin so you can build and upload with one command:

    export DEPLOYGATE_API_TOKEN=your-token
    ./gradlew uploadDeployGateDebug

After installation, the command guides you through uploading a new build, installing it via DeployGate, and confirming a launch event in the dashboard.

iOS SDK​

The iOS SDK is currently not recommended for new projects. The existing SDK has material limitations (no Swift Package Manager support, no simulator binary, no module map), and a redesign is in progress. App distribution, Instant Device, and notifications all work without it. If you ask /deploygate:sdk-setup about iOS, the command will explain the situation and decline to integrate.

/deploygate:logout​

Sign out of DeployGate from this machine. The login is revoked on the server side and the local credential is cleared. Run /deploygate:setup (or any other command) to sign back in when needed.

Last updated on