If you have exceeded the Expo EAS Build free limit, you have three legitimate options and none of them is a trick: wait for the monthly quota to reset, upgrade to a paid plan, or build on your own machine. The free plan includes a set number of lower-priority cloud builds per month, and once you use them up, cloud builds pause until the next cycle. The clean way past that without paying is a local build, which runs the same EAS build process on your hardware and does not consume your cloud build quota. Turtle CLI, the old local builder people still search for, was shut down in 2023, so use the current local build command or generate the native projects and build them yourself.
Short answer
Exceeding the free limit is a billing and capacity boundary, not an error to fix in your code. Per Expo's EAS Build limitations, the free plan provides a monthly allotment of lower-priority builds, up to a portion of which can be iOS, and fast-failed builds no longer count against it. When you run out, run the build locally: per Expo's local builds guide, the local build runner uses your own hardware, so it does not draw on your cloud quota. Turtle CLI, the legacy local builder, was retired with Classic Builds, so use the local runner or prebuild-plus-native-tooling instead.
What the EAS free-tier limit is
The EAS Build free tier gives you a fixed number of cloud builds each month, run at lower priority than paid plans, which means a longer queue as well as a cap. Expo's free plan includes 30 builds per month, up to 15 of which can be iOS, and once you have used that allotment the cloud service stops starting new builds until the quota resets at the start of the next cycle. This is expected behavior for the free tier rather than a fault, so seeing the limit is a sign you are building often, not that something broke.
One helpful detail softens the cap. Since a change in 2024, builds that fail fast, within about three minutes, no longer count against your monthly free quota, so a burst of quick configuration failures does not burn your allotment. That aside, the limit is a real ceiling on cloud builds, and the question is simply how to keep building once you reach it, which comes down to waiting, paying, or moving the build off Expo's cloud onto your own machine.
The three ways past the limit
There are exactly three legitimate responses, and which one fits depends on your timeline and budget. The first is to wait for the reset, which costs nothing and suits you if your remaining builds can happen next cycle. The second is to upgrade to a paid EAS plan, which raises the allotment and build priority, and is the right call if you build frequently and value the managed cloud and faster queues. Neither of these requires any change to how you build.
The third, and the one most people mean by a bypass, is to build locally, which keeps you on the free plan while removing the cloud cap for the builds you run yourself. A local build produces the same artifact as a cloud build but runs on your computer, so it does not consume your monthly quota. This is a supported Expo path, not a workaround, and it is the focus of the next sections, since it is how hobbyist and low-volume developers keep shipping without paying for more cloud builds.
Local EAS builds
Yes, you can run EAS builds locally, and local builds do not count against your cloud build quota because they run entirely on your own hardware. The command is the EAS build local runner, invoked by adding the local flag to the build command, and it executes the same build steps Expo would run in the cloud, just on your machine. So once your free cloud allotment is gone, a local build lets you keep producing installable apps at no additional cost.
The tradeoff is that you provide the build environment. Building iOS locally requires a Mac with Xcode installed, because iOS apps can only be compiled on macOS, while building Android locally requires the Android SDK and a Java Development Kit. You also handle signing credentials locally, which the EAS tooling can manage for you. So a local build shifts the compute from Expo's servers to yours, which is exactly why it sidesteps the cloud quota, at the cost of needing the right toolchain on your own computer.
What about Turtle CLI?
Turtle CLI comes up because it was Expo's older way to build standalone apps locally, but it is deprecated and should not be part of your plan today. Turtle was the local builder for the Classic Build service, and that whole system was shut down in early 2023, with SDK 47 and later unable to use it. So following an old tutorial that tells you to install Turtle CLI will lead you to a dead end on any current Expo project.
The modern replacements do the same job in supported ways. For a local build managed by EAS, the local build runner is the direct successor to Turtle. Alternatively, you can generate the native iOS and Android projects with prebuild and build them with the standard native tools, which does not involve Expo's cloud at all. So when a guide mentions Turtle CLI, mentally substitute the EAS local runner or prebuild-plus-native-build, and you will be on a path that actually works.
Prebuild and build natively
Beyond the EAS local runner, you can drop to the native projects entirely, which gives you the most control and no dependence on Expo services for the build. Running prebuild generates the ios and android folders for your app, after which you build them like any native app: the iOS project in Xcode or with xcodebuild, and the Android project in Android Studio or with the Gradle wrapper. This is a fully standard native build once the folders exist.
This route suits you when you want to integrate with an existing native pipeline, customize the native build, or avoid EAS involvement for cost or control reasons. The cost is that you take on native project management, including keeping the generated folders and native configuration in order and handling signing yourself. For many developers the EAS local runner is simpler because it wraps these steps, but prebuild-plus-native-build is the most independent option and a solid answer to a recurring free-tier limit.
The options compared
Matching each option to what it needs and whether it uses your quota guides the choice. The table below lays it out.
| Option | Uses cloud quota? | What you need |
|---|---|---|
| Wait for reset | Yes, next cycle | Nothing; just time |
| Upgrade a paid plan | Higher allotment | A paid EAS subscription |
| EAS local build | No | Mac and Xcode, or Android SDK and JDK |
| Prebuild plus native | No | Native folders, Xcode or Android Studio |
| Turtle CLI | N/A | Retired; do not use |
Read the last row as a warning: Turtle CLI is gone, and the working no-cost paths are the EAS local build and prebuild-plus-native-build.
Building in your own CI
If you build often enough to hit the limit, moving builds into your own continuous integration is a durable answer that keeps you off the cloud quota. You can run the EAS local runner, or a native build after prebuild, inside a CI service such as GitHub Actions, so each push produces a build on infrastructure you control rather than on Expo's metered cloud. This scales better than manual local builds when a team is involved.
The practical constraints are the same as building locally, moved to the runner. Building iOS in CI needs a macOS runner, since iOS compilation requires macOS, and both platforms need their SDKs installed on the runner. You also store signing credentials as CI secrets and supply them to the build. So your own CI is essentially local builds automated, which trades some setup for unlimited builds on your own hardware and a repeatable pipeline, a good fit once the free cloud tier is consistently too small.
Setup checklist
Working through these steps gets you building again past the free limit. The checklist below covers them.
| Step | Action | Done? |
|---|---|---|
| Confirm the limit | Check that you have used the monthly allotment | [ ] |
| Choose a route | Wait, upgrade, or build locally | [ ] |
| Install the toolchain | Xcode for iOS, Android SDK and JDK for Android | [ ] |
| Run a local build | Use the EAS local runner or prebuild plus native | [ ] |
| Handle credentials | Provide signing keys locally or as CI secrets | [ ] |
| Automate if needed | Move builds into your own CI for volume | [ ] |
The step teams skip most is installing the right toolchain, since a local iOS build needs a Mac with Xcode and there is no way around that requirement.
Where a scan fits
Getting past the build limit is a capacity and cost matter, so a security tool has no role in the quota itself, but the app you build locally still deserves the same security check a cloud build would get.
A scanner like PTKD.com analyzes your built app for security issues such as exposed keys, over-broad permissions, and risky third-party code, mapped to OWASP MASVS. To be clear about the boundary: PTKD does not raise your EAS quota or run your builds, which are between you and Expo or your own machine. It gives the locally-built app the same objective security scan, so moving your builds off the cloud to save on quota does not mean skipping the security review.
What to take away
- Exceeding the EAS free limit is a capacity boundary, not a code error, and you get past it by waiting for the reset, upgrading, or building locally.
- The free plan is a monthly allotment of lower-priority cloud builds, and fast-failed builds no longer count against it.
- Local EAS builds run on your own hardware and do not consume your cloud quota, needing a Mac with Xcode for iOS or the Android SDK and JDK for Android.
- Turtle CLI was shut down in 2023, so use the EAS local build runner or prebuild plus a native build instead of following old Turtle tutorials.
- For volume, move local builds into your own CI, and use a tool like PTKD.com to scan the locally-built app just as you would a cloud build.
