How BuildStack works
A short tour of the pieces, so the rest of the docs make sense.
Workspaces, projects, builds
- A workspace is your team's account. Billing, members, and quotas belong to
the workspace, not to individual people.
- A project is one app inside a workspace.
- A build turns your source plus signing credentials into an artefact (APK,
AAB, or IPA). Android builds come in three types: Development (debug), Preview (standalone release APK, no keystore), and Production (signed release for the stores). You can set the app's version on the build form.
Managed compute
Builds run on BuildStack's own compute (Android on Linux runners, iOS on Mac agents), so there's no toolchain for you to install or keep current. You never manage a build machine.
Managed, sealed signing
Signing credentials (Android keystores, Apple App Store Connect API keys, Google Play service accounts) are encrypted at rest and only decrypted for the moment a build needs them. You upload them once; BuildStack reuses them and never exposes them back.
Two ways to trigger a build
- Git-connected: install the BuildStack GitHub App, map a repo to a project,
and every push builds automatically.
- On demand / programmatic: from the dashboard, the
dbsCLI, or your own CI
via an API key.
Shipping a build
Two independent paths, often confused:
- Publish to Google Play: a build option that uploads a signed AAB to a Play
track. See Publish to Google Play.
- Distribute to testers: share a BuildStack install link through your own
channels, no store involved. See Distribute to testers.
CI runners (bring your own workflow)
Beyond building apps, BuildStack can run your GitHub Actions workflows on its own compute. Add runs-on: buildstack-arc to a job and it runs on a fresh, isolated runner that BuildStack starts for that job. See Run CI on BuildStack.
What you're billed on
- Build quota: the number of app builds per month, set by your plan.
- CI minutes: minutes consumed by your GitHub Actions jobs on BuildStack
runners.