
GitHub Actions is GitHub's built-in CI/CD platform. Pipelines are defined as YAML workflows stored directly in your repository under .github/workflows/, triggered by events such as pushes, pull requests, or manual runs.
The Applivery integration with GitHub Actions allows you to automatically upload a new build to Applivery at the end of each workflow run — making freshly built binaries immediately available to QA teams, stakeholders, or internal users without any manual steps.
There are two approaches to integrating GitHub Actions with Applivery:
Via Fastlane — recommended if your project already uses Fastlane for building and signing. A single lane call handles building and uploading.
Via the Applivery Upload API directly — recommended for any project or when Fastlane is not in use. Uses a
curlstep in your workflow YAML with no additional dependencies.
Prerequisites
Before setting up either approach, make sure you have:
A GitHub repository with Actions enabled.
An Applivery App API Token. Find it in App Settings → API Tokens in the Applivery Dashboard, or see Apps API Token.
A workflow that produces a build artifact (
.ipa,.apk,.aab, or another supported format).
Never hardcode your Applivery token directly in a workflow file — it would be committed to your repository and visible to anyone with read access. Store it as a GitHub Secret so it is masked in logs and injected as an environment variable at runtime.
Open your GitHub repository.
Go to Settings → Secrets and variables → Actions.
Click New repository secret.
Set the name to
APPLIVERY_TOKEN.Paste your Applivery App API Token as the value.
Click Add secret.
Once saved, reference it in your workflow YAML as ${{ secrets.APPLIVERY_TOKEN }}.
If multiple repositories need access to the same token, create an Organization secret instead. Go to your organization's Settings → Secrets and variables → Actions and follow the same process.
This approach is recommended if your project already uses Fastlane. The Applivery Fastlane plugin handles the upload and all metadata in a single lane call.
For full plugin documentation, see Fastlane Integration.
Workflow YAML
name: Build and deploy to Applivery
on:
push:
branches:
- develop
- main
jobs:
deploy:
runs-on: macos-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Set up Ruby
uses: ruby/setup-ruby@v1
with:
ruby-version: '3.2'
bundler-cache: true
- name: Deploy to Applivery via Fastlane
run: bundle exec fastlane ios deploy
env:
APPLIVERY_TOKEN: ${{ secrets.APPLIVERY_TOKEN }}
Fastfile
platform :ios do
lane :deploy do
gym(
scheme: "MyApp",
export_method: "enterprise"
)
applivery(
app_token: ENV["APPLIVERY_TOKEN"],
changelog: ENV["COMMIT_MESSAGE"],
notify_collaborators: true,
notify_message: "New build from GitHub Actions",
tags: "github-actions, #{ENV["GITHUB_REF_NAME"]}"
)
end
end
This approach calls the Applivery Upload API directly from your workflow using curl. It works for any platform and requires no additional tooling.
iOS example
name: Build and deploy iOS to Applivery
on:
push:
branches:
- develop
jobs:
build-and-deploy:
runs-on: macos-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build iOS app
run: |
xcodebuild -scheme MyApp \
-configuration Release \
-archivePath build/MyApp.xcarchive \
archive
xcodebuild -exportArchive \
-archivePath build/MyApp.xcarchive \
-exportPath build/ \
-exportOptionsPlist ExportOptions.plist
- name: Upload to Applivery
run: |
curl 'https://upload.applivery.io/v1/integrations/builds' \
--retry 5 \
--fail \
-H "Authorization: Bearer ${{ secrets.APPLIVERY_TOKEN }}" \
-F "build=@build/MyApp.ipa" \
-F "versionName=${{ github.run_number }}" \
-F "changelog=${{ github.event.head_commit.message }}" \
-F "tags=github-actions, ${{ github.ref_name }}" \
-F "notifyCollaborators=true" \
-F "notifyMessage=New iOS build from GitHub Actions" \
-F "notifyLanguage=en" \
-F "deployer.name=GitHub Actions" \
-F "deployer.info.commit=${{ github.sha }}" \
-F "deployer.info.branch=${{ github.ref_name }}" \
-F "deployer.info.commitMessage=${{ github.event.head_commit.message }}" \
-F "deployer.info.buildUrl=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
-F "deployer.info.buildNumber=${{ github.run_number }}" \
-F "deployer.info.repositoryUrl=${{ github.server_url }}/${{ github.repository }}"
Android example
name: Build and deploy Android to Applivery
on:
push:
branches:
- develop
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Set up JDK
uses: actions/setup-java@v4
with:
java-version: '17'
distribution: 'temurin'
- name: Build Android APK
run: ./gradlew assembleRelease
- name: Upload to Applivery
run: |
curl 'https://upload.applivery.io/v1/integrations/builds' \
--retry 5 \
--fail \
-H "Authorization: Bearer ${{ secrets.APPLIVERY_TOKEN }}" \
-F "build=@app/build/outputs/apk/release/app-release.apk" \
-F "versionName=${{ github.run_number }}" \
-F "changelog=${{ github.event.head_commit.message }}" \
-F "tags=github-actions, ${{ github.ref_name }}" \
-F "notifyCollaborators=true" \
-F "notifyMessage=New Android build from GitHub Actions" \
-F "notifyLanguage=en" \
-F "deployer.name=GitHub Actions" \
-F "deployer.info.commit=${{ github.sha }}" \
-F "deployer.info.branch=${{ github.ref_name }}" \
-F "deployer.info.commitMessage=${{ github.event.head_commit.message }}" \
-F "deployer.info.buildUrl=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
-F "deployer.info.buildNumber=${{ github.run_number }}" \
-F "deployer.info.repositoryUrl=${{ github.server_url }}/${{ github.repository }}"
Advanced: Trigger on tags for Release Builds
A common pattern is to trigger the Applivery upload only on version tags (e.g. v2.4.0), keeping feature branch builds separate from release candidates:
on:
push:
tags:
- 'v*' # Triggers on v1.0.0, v2.4.0-rc1, etc.
Combined with ${{ github.ref_name }} as a tag in Applivery, this makes it easy to filter release builds from the Dashboard.
Advanced: Upload only on successful tests
Use job dependencies to ensure the build is only uploaded to Applivery if tests pass:
jobs:
test:
runs-on: macos-latest
steps:
- uses: actions/checkout@v4
- name: Run tests
run: ./gradlew test
deploy:
runs-on: ubuntu-latest
needs: test # Only runs if the 'test' job succeeds
steps:
- name: Upload to Applivery
run: |
curl ...
GitHub Actions Context Variables
The workflow examples above use GitHub Actions context variables that are automatically available in every workflow:
Variable | Description |
|---|---|
| Full SHA of the commit that triggered the workflow. |
| Short name of the branch or tag (e.g. |
| Sequential run number for the workflow. Useful as a |
| Unique numeric ID for the workflow run. Used to construct the build URL. |
| Commit message of the commit that triggered the workflow. Useful as |
| Base URL of the GitHub instance (e.g. |
| Owner and repository name (e.g. |
| The Applivery App Token stored as a GitHub Secret. |
For the full reference, see the GitHub Actions context documentation.
Key upload parameters reference
The curl form fields map directly to the Applivery Upload API. The most commonly used parameters:
Parameter | Description |
|---|---|
| The binary file to upload ( |
| Human-readable label for the build. Using |
| Release notes shown in the Dashboard and notification emails. |
| Comma-separated tags for filtering builds. E.g. |
| Set to |
| Custom message included in the notification email. |
| CI platform name shown in the Applivery Dashboard. |
| Git commit SHA. |
| Git branch or tag name. |
| Workflow run number. |
| Direct URL to the GitHub Actions workflow run. |
For the complete parameter reference, see POST – Upload a Build.