Step 6: Validate Environment Variables at Runtime with Zod

Reading process.env directly across the app is fragile — a missing variable silently becomes undefined. I use Zod to validate all environment variables at app startup, so the app fails loudly if something is missing.

Here's env.ts:

import * as z from 'zod';



const createEnv = () => {

  const EnvSchema = z.object({

    API_URL: z.string(),

    SOCKETIO_URL: z.string(),

    APP_VARIANT: z.string(),

    TAWK_KEY: z.string(),

  });



  const envVars = {

    API_URL: process.env.EXPO_PUBLIC_API_URL,

    SOCKETIO_URL: process.env.EXPO_PUBLIC_SOCKETIO_URL,

    APP_VARIANT: process.env.EXPO_PUBLIC_APP_VARIANT,

    TAWK_KEY: process.env.EXPO_PUBLIC_TAWK_KEY,

  };



  const parsedEnv = EnvSchema.safeParse(envVars);



  if (!parsedEnv.success) {

    throw new Error(

      `Invalid env provided.

  The following variables are missing or invalid:

  ${Object.entries(parsedEnv.error.flatten().fieldErrors)

        .map(([k, v]) => `- ${k}: ${v}`)

        .join('\n')}

  `,

    );

  }



  return parsedEnv.data ?? {};

};



export const env = createEnv();

Note: if you add extra keys to EnvSchema (like an Agora app ID), remember to add a matching EXPO_PUBLIC_* entry to envVars and to your .env.local / EAS environment — otherwise Zod will throw at startup.

Now anywhere in the app, I import a single typed env object:

import axios from 'axios';

import { env } from '@/configs/env';



const api = axios.create({

  baseURL: env.API_URL,

});

No more process.env.EXPO_PUBLIC_API_URL scattered across files — and a missing variable crashes in dev, not in production.

Step 7: Add Convenience Scripts to package.json

To avoid typing long EAS commands, I added scripts for each environment:

{

  "scripts": {

    "dev": "npx expo start",

    "build:dev:android": "eas env:pull development --non-interactive && eas build --profile development --platform android --local",

    "build:preview:android": "eas env:pull preview --non-interactive && eas build --profile preview --platform android --local",

    "build:prod:android": "eas env:pull production --non-interactive && eas build --profile production --platform android --local",

    "update:preview:android": "eas env:pull preview --non-interactive && eas update --channel preview --platform android --environment preview",

    "update:prod:android": "eas env:pull production --non-interactive && eas update --channel production --platform android --environment production"

  }

}

Each script:

1. Pulls the latest env vars from EAS for that environment.


2. Runs the build (or OTA update) against the matching profile and channel.

So to build a staging APK, I just run:

yarn build:preview:android

And to build a dev client APK:

yarn build:dev:android

The result: development and preview builds installed side by side on the same phone.

Step 8: Firebase Config per Environment

Push notifications and analytics need separate Firebase projects per environment. In my project root, I keep four files:

google-services.json          # production Android

google-services-dev.json      # dev + preview Android

GoogleService-Info.plist      # production iOS

GoogleService-Info-dev.plist  # dev + preview iOS

app.config.ts picks the right one based on APP_VARIANT (see Step 3). Only the production files are referenced as defaults in app.json.

Step 9: Putting It All Together

Here's the full flow when I want a staging build:

1. 
   APP_VARIANT=preview is set by the preview EAS profile.


2. 
   app.config.ts reads it → the app becomes Bayt (Preview) with bundle ID com.jocanola.bayttaalim.preview.


3. 
   eas env:pull preview injects the EXPO_PUBLIC_* variables into the build.


4. 
   env.ts validates them with Zod.


5. The app boots with the staging API URL, socket URL, and Firebase config.


6. The build is published to the preview OTA channel.

One command, one environment, zero manual switching.

Final Thoughts

Setting up multiple environments in Expo takes a bit of upfront work, but it pays off every single day. Once it's in place:

• You can install dev, staging, and prod builds on the same phone.


• You'll never accidentally ship a build pointing at the wrong API.


• QA gets reproducible staging builds.


• OTA updates stay scoped to the right audience.


• New team members can build for any environment with a single command.

The combination of eas.json profiles, a dynamic app.config.ts, EAS environment variables, and Zod validation gives you a setup that's both flexible and safe.

Thanks for reading till the end. Next time, I'll cover how to automate these builds with GitHub Actions so every push to staging or main produces the right build automatically. Stay tuned!