a web UI for fastlane,
on your own machine
A browser interface for the lanes you already have, on hardware you own. Pick a lane, run it, watch the output stream, download the artifact. It drives fastlane and your Fastfile — it doesn't replace them.
Runs on macOS and Linux. iOS builds need a Mac, as always; Android builds do not.
$ laneyard --why
- you keep the keys
- Certificates, keystores, profiles, store credentials — everything needed to publish under your name — stays on your machine. Hosted CI is a third party holding all of it. Here they sit encrypted in a vault, and a keystore or .p8 is written to disk only for the length of the build that needs it.
- minutes stop existing
- Hardware you already own costs less than a year of most CI plans, and never bills by the second. Long builds stop being a budget decision.
- it is just fastlane
- No new DSL, no YAML dialect, no vendor config to port. Laneyard reads the Fastfile you already have and asks your fastlane what it can do. The adaptation goes one way: credentials reach your lanes under the variable names your Fastfile already reads, and where an Android build needs a key.properties no clone carries, Laneyard writes it for the length of the run instead of asking you to rewrite your build script. Where setup finds a credential named by a path only your laptop has, it offers the edit with the diff — decline it and the project builds exactly as before.
- it says what will hang at 2am
- A readiness checklist per project: the repository answering without a password, the bundle installed, an App Store Connect key rather than an expiring session, match readonly with its passphrase, no lane that stops and asks, and every variable your lanes read present — the usual reason a laptop build fails on a server is a .env that was never committed. It reads your Fastfile the way you wrote it, and where something is out of reach — an import, an action of your own — it says could not tell instead of ticking. A tick means “looked, and it is fine”, never “saw nothing”. It explains; it never rewrites your Fastfile to go green, and never blocks a build.
- you can fix a lane without an SSH session
- A text editor for the Fastfile, in the browser. Every save is verified — written byte-for-byte, parsed by fastlane, and if it cannot parse, the previous content is already back and your work still on screen. A broken Fastfile never reaches a build.
$ laneyard setup
Run it inside a project that already uses fastlane. It reads what is there and writes the config for you.
$ cd ~/code/your-project $ laneyard setup Project “your-project” is set up · ~/.laneyard/config.yml repo git@github.com:you/your-project.git (main) fastlane fastlane runtime bundle artifacts **/*.ipa, **/*.app.dSYM.zip
Then open the browser. Your lanes are listed, because Laneyard asked your project's own fastlane — plugins included.
$ laneyard --compare
| Laneyard | Hosted CI | Self-hosted runner | |
|---|---|---|---|
| who holds your signing keys | you | the vendor | you |
| cost per build | electricity | per minute | electricity |
| setup | one command | a signup form | a weekend |
| works offline | yes | no | yes |
| build queue across a team | yes, serial | yes | yes |
| runs on pull requests | planned | yes | yes |
Laneyard's queue is serial: runs drain one at a time across every project, in order, and a queued run survives a restart. If your team needs parallel builds across a fleet, use something else — Laneyard is for one machine you control.
$ laneyard --price
[00:00:00]: computing invoice [00:00:00]: seats 0 [00:00:00]: build minutes unmetered [00:00:00]: concurrency fee 0.00 [00:00:00]: ✓ total 0.00 — self-hosting is free forever
Self-hosting is free forever, and the source is MIT licensed. Not a trial, not an expiring tier: you run it on your own machine, so there is nothing of ours to bill you for.
A paid hosted option may follow later, for people who would rather not keep a machine running — the way Coolify does it. It would never take anything from the self-hosted version, which stays free and open — better said now than found in a changelog.
$ laneyard --roadmap
Read the markers the way the tool does: ✓ shipped, ▸ being built, ○ planned. Nothing here is a refusal — it is an order of work.
- ✓ declare a project, clone it, list its lanes, run one, watch it live, download the artifact
- ✓ configuration entirely in files you can version and back up
- ✓ adopt an existing fastlane project with one command
- ✓ encrypted secret vault, outside your repository, and log redaction — with one command to import the fastlane/.env you already have
- ✓ build queue, cancellation, timeouts
- ✓ a build number per project, handed to every run as LANEYARD_BUILD_NUMBER — nothing to configure, and settable by hand
- ✓ every run listed by the build and version it produced, not by a row number
- ✓ a checklist that gets a project running unattended
- ✓ edit the Fastfile in the browser, verified on every save
- ✓ signing credentials stored whole — an App Store Connect key, an Android keystore, a Play Store service account, each with the fields that make it usable — written to disk only for the length of a run
- ✓ remove a project — and everything Laneyard holds for it — from the interface or the command line, behind a typed confirmation
- ✓ named accounts, a builder role that never sees a credential and reaches only the projects you grant it, and a name and password everyone changes themselves
- ✓ setup names the credentials a Fastfile hardcodes, and offers — refusably — to lift them into the vault and patch the file
- ○ git-triggered and scheduled builds
Early, and saying so. If one of the unshipped lines is what would make Laneyard useful to you, the issue tracker is the place to say which — it is how the order gets decided.