Create your first project
Point AppRelay at a folder and let it scan, detect your stacks, and prefill lanes — then confirm the review table and start shipping.
Last updated 2026-07-02
The fastest way to set up a project is to let AppRelay read your disk. You point it at a folder, it scans the subfolders, recognizes each stack, reads the real version numbers, and prefills lanes, repos, and suggested distributions. You confirm the results in a review table and you're running — usually in about a minute.
Before you start
- Have your repositories checked out locally, in one parent folder if possible (for a product family, that's the folder that contains each repo).
- Install the toolchains for the stacks you want to build — see Installing AppRelay.
Scan a folder
- Choose “Scan a folder.” On the empty-state screen, pick Scan a folder (the primary option) and select the parent folder of your repositories.
- Let AppRelay detect your stacks. It walks the subfolders and reads real project files to identify each toolchain and its current version (details below).
- Review the results. A table appears with a checkbox and editable fields for every detected lane, repo, and suggested distribution.
- Confirm and save. Correct anything that's off, uncheck anything you don't want, and save. Your project opens on the Overview.
What detection recognizes
Each toolchain adapter contributes its own detection signals, so onboarding can recognize any stack in the library. Highlights:
| Signal on disk | Detected as | Version read from |
|---|---|---|
*.xcodeproj / *.xcworkspace | Xcode lane (scheme, bundle id; Pods → workspace) | MARKETING_VERSION in the pbxproj |
app/build.gradle(.kts) | Gradle lane | versionName + versionCode (literal or derived) |
package.json | React Native, Expo, or a Node web framework (Next/Vite/Vue/Svelte), Electron, or Tauri — disambiguated by dependencies | version in package.json |
pubspec.yaml | Flutter lane | version: in the pubspec |
Cargo.toml / src-tauri/tauri.conf.json | Rust / Tauri | Cargo.toml |
app.json / app.config.* | Expo | Expo app config |
Dockerfile | A Docker distribution candidate | — |
a .git repo | A repository row (branch from git) | — |
Each detected lane is pre-linked to the matching built-in recipe and a sensible default distribution — for example Expo → EAS, Next.js → Vercel, Gradle → Play internal track. You confirm or change these in the review table.
#RRGGBB tokens into the project's brand palette.The review table
AppRelay reads the real files rather than trusting a guess, and then asks you to confirm. In the table you can:
- uncheck lanes or repos you don't want in this project;
- edit any prefilled field — scheme, module directory, bundle/application id, version source, and the suggested distribution;
- see a “couldn't confidently detect — please confirm” flag on anything ambiguous (for example, a monorepo with several
package.jsonfiles).
The repo root is stored per-machine
The folder you scanned is remembered as the project's repo root — but it's stored on this machine, keyed to the project, not inside the project data itself. That's what keeps a project portable: the configuration holds only relative paths, so when you open the same project on another machine it re-prompts for where the repos live. See Projects, repositories & the repo root.
Adding a second project
Once you have one project, use New Project to scan another folder or import a .relay. Each project is independent, with its own repos, lanes, brand, and (optionally) backend.
Next steps
- Lanes, toolchains & version sources — fine-tune how each target builds
- Build ≠ Distribute — add destinations to a lane