Building an Expo app without an Expo account

There are two separate questions here, and conflating them is why the answer is confusing. Can you build an Expo app without an Expo account? Yes. Can you use eas build --local without one? No — and that surprises people, because “local” sounds like it should mean self-contained.

What `eas build --local` requires

Expo’s own documentation is clear about this, which is worth saying plainly because it is often reported as a gotcha rather than a documented design decision. The local builds reference states the requirement directly:

“Run eas login, or alternatively, set EXPO_TOKEN”— Expo documentation, EAS Build local builds

The same page describes what still crosses the network during a local build: it confirms that the project @account/slug exists, and, if you are using managed credentials, it downloads them. Everything else — the compile, the signing, the artifact — happens on your machine.

So the flag is accurate about where the work happens. It is not a claim about independence. A local build still requires a valid session against a remote account, and if you use managed credentials, your signing material still round-trips from Expo’s servers to your machine at build time.

Why this matters more than it sounds

For most people, most days, it does not matter at all. It starts mattering when the answer to “who can stop us shipping?” has to be nobody outside the room: when a token expires mid-incident, when an audit asks where the distribution certificate is stored, or when a policy forbids third-party custody of signing material outright.

The documented limitations, while you are here

The same page lists constraints that are easy to hit and worth knowing before you plan around local builds:

One platform at a time — the all option is disabled.
No caching.
Version-pinning fields in eas.json (node, yarn, fastlane, cocoapods, ndk, image) are ignored.
Secret-visibility environment variables are not available; set them locally instead.
You are responsible for having the right toolchain installed.
Windows is not officially supported or tested, WSL notwithstanding.

Path one: prebuild, then build natively

This is the answer that predates EAS and still works. npx expo prebuild generates the ios/ and android/ directories from your config, and from that point you have an ordinary native project.

npx expo prebuild
# then, ordinary native buildsxcodebuild -workspace ios/YourApp.xcworkspace -scheme YourApp archive ./gradlew :app:bundleRelease

No account is involved, because nothing in that sequence talks to Expo. What you have taken on instead is everything EAS was doing for you: importing a certificate into a keychain without triggering an interactive prompt, generating an ExportOptions.plist that matches your provisioning profile, re-signing the Android artifact with a real upload key rather than the debug key the template uses, driving altool and the Play Developer API for submission, and keeping version codes monotonic.

None of that is hard, exactly. It is just a lot of small, specific, undocumented-in-one-place knowledge, and it is the reason most teams pay somebody to do it.

Path two: automate that, without adding an account

This is what leas is. It is the second path with the tedium removed: the same native build, plus signing, submission, over-the-air updates, and a preflight command that checks your credentials before a build starts rather than forty minutes into one.

npx leas doctor npx leas build --platform all --profile production --auto-submit

There is no leas login, because there is no account to log in to. Your credentials live in your project and in your own repository secrets. Cloud builds, when you want them, dispatch a workflow in your GitHub repository running on runners you rent — so the machine doing the signing is one you control, and there is no upload endpoint on our side to send a certificate to.

Which one you should actually use

Genuinely, in the order we would recommend them:

If…	Use
You want zero infrastructure thinking, you have budget, and you may not own a Mac	EAS. It is a good product and this is exactly what it is for. Managed credentials are a real convenience, not a trick.
You ship rarely, enjoy the details, and want no dependencies at all	Prebuild and native tools. Free, fully under your control, and you will learn a lot.
You ship often, own a Mac, and want the automation without the custody	leas. The second path, automated.
Policy forbids a third party holding your signing keys	leas, or the second path by hand. This is the case where the distinction stops being a preference.

One thing nobody can offer you

iOS builds require Apple hardware. Apple’s macOS licence forbids running macOS on non-Apple machines, so every iOS build in the world happens on somebody’s Mac — yours, a rented one, or a vendor’s. Any tool claiming otherwise is describing somebody else’s Mac. The only question is whose, and who holds the certificate on it.