Hosted builds

A hosted build takes your app's source, compiles it on a Platform runner, signs it with your credentials in custody, and gives you back a downloadable artifact.

Builds are submitted from the CLI: every platform build is the only way to start one. The web dashboard is where you watch them, with status, live logs, and the finished artifacts for every build your organization has run.

Submit a build#

From your app directory, with the CLI connected:

every platform build

The CLI snapshots your source (honoring .everywhereignore), uploads it straight to storage, and submits one build covering every target in build.targets:

→ snapshotting source (honoring .everywhereignore)
→ 412 files, 3.4MB
→ uploading snapshot
✓ submitted build_9xF3mQ2vLd8pT4nR6sYbKc1w for macOS-arm64
  ▸ watch it live → https://platform.rubyeverywhere.com/builds/build_9xF3mQ2vLd8pT4nR6sYbKc1w

Choosing targets#

Targets come from build.targets in everywhere.yml, which keeps the matrix in one place. --target overrides it for a single run, and takes a comma-separated list of os-arch with an optional :channel suffix:

every platform build --target macos-arm64
every platform build --target ios-arm64:testflight,android-arm64:play
every platform build --target android-arm64 --channel play

--channel sets the default channel for targets with no suffix of their own, and defaults to direct. With no targets configured anywhere, the CLI builds macos-arm64.

These are the target/channel combinations hosted runners accept today:

Anything else is rejected at submission with the supported list, before a runner is dispatched. One submission can carry up to 20 targets.

Follow the logs#

every platform build waits by default. It tails each target's log and prints a permanent line every time a target crosses a phase boundary. Most of a build's wall clock goes before the first log byte, on finding a runner and then preparing its toolchain, so those waits are named too, including which runner OS the target is waiting on. macOS targets and iOS build on macOS; Android builds on Linux.

  ▸ hosted macOS/Linux runners usually start within a few minutes
→ macOS-arm64 → waiting for a hosted macOS runner to become available
→ macOS-arm64 → preparing the build toolchain
→ macOS-arm64 → building
→ Android-arm64 → waiting for a hosted Linux runner to become available

Pass --no-wait to submit and return at once. The build keeps running, and the build page has everything.

If the CLI loses contact with the Platform mid-tail it retries, and gives up only after several failed polls in a row. The build itself is unaffected, and the artifacts wait on the build page.

Download the result#

When a target succeeds, the CLI downloads its artifact into dist/:

✓ macOS-arm64 ✓  dist/Notes.zip
✓ build build_9xF3mQ2vLd8pT4nR6sYbKc1w complete

Use --output to save somewhere else, or --no-download to just print the download URLs.

every platform build --output build/artifacts
every platform build --no-download

The macOS artifact is the same signed, notarized app a local every release produces. The signing and notarization happened on the runner, with your credentials in custody.

When a build is refused#

The Platform preflights a submission before it burns a runner, so most mistakes come back in seconds with the fix named:

• Unsupported target. The os:channel pair is not buildable, and the error lists the ones that are.
• Missing credentials. The target's signing requirements are not all verified yet. The error names each missing credential and links to Credentials.
• Mobile target not in remote mode. iOS and Android builds need mode: remote with an absolute http(s) remote.url in everywhere.yml.
• Invalid Android applicationId. platforms.android.bundle_id must be two or more dot-separated segments of letters, digits and _, each starting with a letter. Hyphens are legal in a bundle id and never in an Android package name.
• Quota or app limit reached. You are at your plan's monthly build limit, or this bundle id would be a new app beyond your plan's app count.

From the web#

Every build appears in the dashboard under Builds with its per-target status, the same logs the CLI tails, and a download for each artifact, so teammates who only need the finished app never have to install the CLI. Promoting a succeeded build into a release happens there too.