I Test My App from an Uber. Preview Environments Make That Possible.
Draft Disclaimer: Please note that this article is currently in draft form and may undergo revisions before final publication. The content, including information, opinions, and recommendations, is subject to change and may not represent the final version. We appreciate your understanding and patience as we work to refine and improve the quality of this article. Your feedback is valuable in shaping the final release.
Language Mismatch Disclaimer: Please be aware that the language of this article may not match the language settings of your browser or device.
Do you want to read articles in English instead ?
TL;DR
What: Per-PR preview environments that give every pull request its own isolated backend, paired with Expo updates to test mobile builds against them. Why: I needed to QA my app from anywhere, not just from my laptop. How: Each PR spins up a small AWS instance mirroring staging. Expo's env vars point the mobile app at the preview URL. When the PR closes, the environment tears down. Here is what I built and why it matters if you are shipping a mobile app.
It Started in an Uber
I was 30 minutes from home, sitting in an Uber with nothing but my phone. I pulled up GitHub Projects for Traxelio, my fleet management app, and found a small issue I could knock out. A low-hanging fruit.
The code change was simple. But how do I verify it works? I am not at my desk. I do not have my laptop. That is the problem I solved with preview environments, and if you are building a mobile app, this setup could save you real time.
What I Built
Every time I open a pull request, a new environment spins up automatically. A full copy of my staging setup: API, database, everything. One isolated instance per PR, each with its own URL.
This means every feature branch gets its own backend. No shared staging where multiple PRs step on each other. No "wait for this to merge first." Each PR lives in its own world.
When the PR closes, the entire environment tears down. No cleanup. No lingering resources.
Why This Matters to You
If you have ever merged a PR into staging just to test it, you know the pain. You pollute the shared environment. Other changes interfere with yours. You find a bug but you are not sure if it is yours or someone else's.
Preview environments eliminate that. You test before merging. You test in isolation. And you catch problems earlier, when they are cheap to fix.
You do not need a big team to benefit from this. I do my own QA. No dedicated testers. But this setup gives me the same workflow a QA team would use: open the preview URL, test the feature, verify edge cases, then approve or push a fix.
If you are a solo dev or a small team, this is how you get professional-grade QA without the headcount.
It Costs Almost Nothing
Each preview environment runs on a t3.small instance with 20GB of EBS storage. That is roughly $0.60 per day per open PR. When the PR closes, everything tears down.
Two PRs open for three days? About $3.60. That is less than a coffee. For isolated, on-demand testing environments that keep your staging clean, it is a no-brainer.
The Expo Connection
This is the part that makes it powerful for mobile. Traxelio is built with Expo. When I want to test a mobile build against a specific preview environment, I run expo update with the environment variable pointing at the preview URL.
That gives me a mobile app on my phone that talks to the preview backend. Full flow: frontend, API, data. All from my phone, all against an environment that exists only for that PR.
If you are building with Expo, this pattern works out of the box. Set the env var, push the update, test on your device. No special tooling. No simulator required.
Could You Skip This and Just Use Staging?
Yes. I have a staging environment that deploys on every push to the main branch. It is a core part of my pipeline. You could merge first, test on staging, and call it done.
But preview environments let you test before the merge. That is the difference. You catch issues earlier. You keep staging clean. And you do not block other work while you iterate on a feature.
It is not strictly necessary. But once you have it, you will not go back. The confidence it gives you before hitting "merge" is worth the $0.60.
The Full Pipeline
Here is how the pieces fit together. If you are setting up something similar, this is the model:
- Preview: Every PR gets its own environment. Test features in isolation before merging.
- Staging: Deploys on every push to the main branch. The integration checkpoint where everything comes together.
- Production: Deploys when you push to the release branch. The final gate.
Three layers. Clear purpose for each one. Preview catches issues early. Staging validates the full picture. Production is the real thing.
What You Can Take from This
You do not need a complex setup to get preview environments working. The core idea is simple: spin up a copy of your backend for each PR, tear it down when the PR closes.
If you are building a mobile app with Expo, pair it with expo update and you can test full end-to-end flows from your phone. Anywhere. Anytime.
I built this so I could QA my app from an Uber. But the real value is broader. It is faster feedback, cleaner staging, and the confidence to ship knowing you tested the actual change in isolation.
For $0.60 a day, that is a good trade.
