DEV Community: kaz-builds-staff

11 Failures Before My CI/CD Pipeline Worked: A VibeCoder's Guide to Expo + GitHub Actions + DeployGate

kaz-builds-staff — Fri, 10 Apr 2026 08:34:37 +0000

I can't write code.

That's not quite right. I describe what I want, Claude writes the code, and I focus on what to build. I'm what people call a VibeCoder — someone who builds products with AI, spending their time on product decisions rather than syntax.

I'm building "Arc," a mobile CRM for bodywork therapists, using Expo, React Native, and Supabase. The MVP is 85% done — 28 files, 27 screens, 18 of them functional.

The problem wasn't building it. The problem was getting it onto a tester's phone.

The last mile is the hardest mile

Writing code is fast. Tell Claude "build this screen" and something functional appears in minutes.

But putting that build on a tester's iPhone requires:

Building with Xcode
Generating an .ipa file
Uploading it somewhere
Telling testers "there's a new version"

For a VibeCoder, this "last mile" is the biggest bottleneck — not writing code, but delivering what you've written.

TestFlight? Apple's review queue adds hours or days. Expo Go? Can't use native modules. EAS Build (cloud)? Monthly subscription for a solo dev feels wrong.

The answer turned out to be DeployGate + a self-hosted GitHub Actions runner on my 13-inch M5 MacBook Air. Push to main, wait ~10 minutes, and every tester gets the latest build at a fixed URL. $0/month. Unlimited builds.

What I wanted

Simple, right? Here's what actually happened — 11 failures before attempt #12 finally worked.

Attempt #1 — Workflow collision

Error: Build failed at 3:54 — crashed on "Embed Pods Frameworks."

Cause: Two workflows triggered on the same push to main — one for DeployGate, one for TestFlight. My Mac's Xcode resources couldn't handle both simultaneously.

Fix: Moved the TestFlight workflow out of the active directory.

mkdir -p .github/workflows-disabled
mv .github/workflows/build-and-submit.yml .github/workflows-disabled/

Attempts #2–3 — Binary files in the repo

Error: Every push uploaded 15MB of binary data.

Cause: A .ipa file and an Apple certificate had been accidentally committed.

Fix: Added them to .gitignore and purged from history.

build-*.ipa
AppleWWDRCAG3.cer

Lesson: build artifacts never belong in a repository.

Attempts #4–5 — Package drift

Error: Same "Embed Pods Frameworks" crash.

Cause: Between sessions, react-native had silently updated from 0.83.2 to 0.83.4, and react-native-worklets appeared as a new peer dependency of react-native-reanimated.

How I found it: Checked out the last known working commit's package.json and rebuilt.

git checkout 89fcbe9 -- package.json package-lock.json
npm ci
eas build --platform ios --profile preview --local
# → Build successful

Fix: Pinned packages to the stable version, then formally added the missing dependency.

Attempts #6–7 — Stale runner cache

Error: Builds pass locally, fail in CI.

Cause: The self-hosted runner's working directory had stale node_modules and Xcode DerivedData from previous runs.

Fix: Added a cache-clearing step to the workflow.

- name: Clean caches
  run: |
    rm -rf ~/Library/Developer/Xcode/DerivedData/Arc-*
    rm -rf /tmp/eas-build-local-nodejs
    rm -rf /tmp/eas-cli-nodejs

Attempts #8–9 — Credentials source ignored

Error: Console showed Using remote iOS credentials (Expo server) when I wanted local credentials.

Cause: The EAS_CREDENTIALS_SOURCE=local environment variable was silently ignored by eas-cli 18.5.0.

Fix: Set it directly in eas.json.

"preview": {
  "distribution": "internal",
  "credentialsSource": "local"
}

Attempt #10 — Missing credentials file

Error: credentials.json does not exist in the project root directory

Cause: credentials.json is in .gitignore (as it should be), so the runner's checkout didn't include it.

Fix: Copied it from the Mac's home directory in the workflow.

- name: Copy credentials
  run: |
    cp ~/client-crm/credentials.json ./credentials.json
    cp -r ~/client-crm/credentials ./credentials

Attempt #11 — Locked keychain

Error: Everything compiled fine. Failed only at the final code-signing step ("Embed Pods Frameworks").

Cause: The self-hosted runner runs as a LaunchAgent without access to the GUI session's keychain.

Fix: Explicitly unlock the keychain in the workflow.

- name: Unlock keychain
  run: security unlock-keychain -p "${{ secrets.KEYCHAIN_PASSWORD }}" ~/Library/Keychains/login.keychain-db

Store your Mac login password in GitHub Secrets as KEYCHAIN_PASSWORD.

Attempt #12 — It worked 🎉

✔ Using local iOS credentials (credentials.json)
✔ Archive Succeeded
✔ Successfully exported and signed the ipa file
✔ Uploading to DeployGate...
✔ Distribution page updated

From git push to a tester opening the build on their phone: about 10 minutes.

The final workflow

Here's the complete GitHub Actions workflow that survived all 11 failures:

name: Build & Deploy to DeployGate
on:
  push:
    branches: [main]
  workflow_dispatch:

jobs:
  build-and-deploy:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v4

      - name: Clean caches
        run: |
          rm -rf ~/Library/Developer/Xcode/DerivedData/Arc-*
          rm -rf /tmp/eas-build-local-nodejs
          rm -rf /tmp/eas-cli-nodejs

      - name: Install dependencies
        run: npm ci

      - name: Copy credentials
        run: |
          cp ~/client-crm/credentials.json ./credentials.json
          cp -r ~/client-crm/credentials ./credentials

      - name: Unlock keychain
        run: security unlock-keychain -p "${{ secrets.KEYCHAIN_PASSWORD }}" ~/Library/Keychains/login.keychain-db

      - name: Build .ipa
        run: eas build --platform ios --profile preview --local --non-interactive

      - name: Upload to DeployGate & update distribution page
        run: |
          IPA_FILE=$(ls build-*.ipa | head -1)
          curl -X POST \
            "https://deploygate.com/api/users/${DEPLOYGATE_OWNER}/apps" \
            -H "Authorization: Bearer ${DEPLOYGATE_API_TOKEN}" \
            -F "file=@${IPA_FILE}" \
            --form-string "distribution_key=${DEPLOYGATE_DIST_KEY}" \
            --form-string "release_note=$(git log -1 --pretty=%B)"
        env:
          DEPLOYGATE_OWNER: ${{ secrets.DEPLOYGATE_OWNER }}
          DEPLOYGATE_API_TOKEN: ${{ secrets.DEPLOYGATE_API_TOKEN }}
          DEPLOYGATE_DIST_KEY: ${{ secrets.DEPLOYGATE_DIST_KEY }}

The DeployGate upload API accepts both the .ipa file and distribution page parameters in a single call — pass distribution_key to update an existing distribution page and release_note to auto-populate release notes from your commit message. Testers access the same fixed URL every time. No new links to send, no app store to check.

Why DeployGate instead of alternatives?

I tried the obvious options first:

TestFlight: Apple's review queue for the first build of each version can take hours to days. When you're iterating multiple times per day, that's a dealbreaker.
EAS Build (cloud): Works great, but the monthly cost adds up for a solo developer building across multiple projects.
Expo Go: Fine for early prototyping, but the moment you add native modules (and you will), it stops working.

DeployGate fit because: no review queue, free tier for indie devs, and an API simple enough to add to a GitHub Actions workflow in one curl command. Testers don't need accounts — they open a link and install.

What I learned

After 11 failures, every lesson is burned in:

One workflow per trigger. Two workflows on the same push with shared Xcode resources will collide.
Pin your packages. npm ci only protects you if package-lock.json hasn't drifted.
Self-hosted runners need manual cache hygiene. Unlike cloud runners, they accumulate state between builds.
eas.json over environment variables. Some CLI tools silently ignore env vars for credential configuration.
Keychain access is not automatic. LaunchAgent processes can't see your GUI keychain without explicit unlock.
Keep credentials out of the repo, but script their placement. Copy them from a known location on the build machine.

I'm a solo developer building multiple products — a CRM for bodywork therapists, a learning tool for structural consultants, and a few things I can't talk about yet.

Making mistakes along the way and sharing all of it here. Follow @kazbuildsstaff for real build-in-public, not the highlight reel.

I Cut My Cold Start by 82% Without Changing a Single Line of Code

kaz-builds-staff — Fri, 10 Apr 2026 02:46:33 +0000

I was setting up Claude connectors for my Supabase project — checking permissions, tightening auth scopes — when I noticed something.

Region: South Asia (Mumbai)

Wait. I'm in Tokyo. All my beta testers are in Japan.
I was sure I had picked Tokyo when I created this project. But the dropdown said otherwise. Probably got pulled toward India because I had another India-related project on my mind at the time. One wrong click, months ago, that I never looked at again.

And it explained everything.

The Slow First Load That Wouldn't Go Away

For weeks, my app's cold start had been bugging me. Not enough to stop feature development — I was building in parallel across multiple products — but enough to notice every single time I opened the app.
I'd already tried the right things:

Optimistic UI to decouple data fetching from rendering
Skeleton screens to improve perceived load time

These helped for navigating between pages. But that first load — opening the app, hitting login — always felt sluggish. I assumed it was a Next.js SSR issue or a Supabase query that needed optimization.

It wasn't. The database was just in the wrong country.

The Migration Tool That Wouldn't Migrate

No problem, I thought. Supabase has a project migration tool. I'll just move it to Tokyo.

Found the "Restore to new project" button in the dashboard. Me and my AI pair programmer literally celebrated.

Clicked it. Read the modal:

"Project region will stay the same: ap-south-1"

The one tool designed for this exact situation... only works within the same region.

Going the Hard Way

So I went manual.

pg_dump → GitHub Actions → new Tokyo project.
First wall: pg_dump version 16 can't dump a Postgres 17 database. No useful error message. Just a silent failure in CI. Had to manually install postgresql-client-17 in the workflow.

Data migrated. Done?

Not even close. The migration docs had warned me — I just didn't appreciate what "manual reconfiguration" actually meant:

Google OAuth redirect URLs → all pointing to the old project
Every Vercel environment variable → old project URL and keys
Supabase anon key, secret key, project URL in .env → all old

I was basically rewiring the entire authentication system by hand.

And while I was knee-deep in this, Vercel builds started failing from a completely unrelated bug (Date.now() called during render). Two simultaneous failures. Your brain merges them into one impossible problem.

Was It Worth It?

I measured latency before and after. Here are the honest numbers:

Median latency: nearly identical. ~40ms from both regions. Supabase's CDN does an impressive job absorbing the geographic difference for cached requests.
But the cold start — that first request when your app wakes up?

367ms → 64ms.

That's 82% faster. And that's the moment your users actually feel. The login screen. The first dashboard load. The moment they decide if your app is "fast" or "slow."

All those optimistic UI improvements I'd built? They were masking a structural problem. The foundation was off.

Three Things I'd Tell Anyone Starting a Supabase Project

Region selection is a one-way door. Pick the region closest to your first users — not your future ones, not the project that's on your mind that day.
Supabase's built-in migration = same region only. Cross-region means pg_dump, manual auth rewiring, and a full env var rebuild. Budget a day, not an hour.
Measure your latency before you migrate. Once you switch, that "before" data is gone forever.

I'm building multiple products right now — a structural consulting SaaS, a management dashboard for a wellness business, and some things I can't talk about yet.

Making mistakes along the way and sharing all of it here. Follow @kazbuildsstaff if you want real build-in-public, not the highlight reel.