EAS Env Vars for Firebase Apps

Keep Firebase-backed Expo builds predictable across development, preview, and production without accidentally shipping real secrets in the mobile bundle.

June 16, 2026 12 min read Paddy B

ExpoEAS BuildFirebaseEnvironment VariablesSecrets

The short version

Use EXPO_PUBLIC_ variables for Firebase client config, map each EAS build profile to an EAS environment, reserve secret variables for build-time server credentials, and pull environment files locally when you need to mirror a cloud build.

The biggest mental model: anything your app reads at runtime is visible to someone who has the app. EAS secret variables protect values on the build worker, but they cannot make embedded client values private.

1. Separate public config from secrets

Firebase web config belongs in the app. It identifies your Firebase project and is protected by Auth, App Check, rules, and backend checks.

EXPO_PUBLIC_FIREBASE_API_KEY=...
EXPO_PUBLIC_FIREBASE_AUTH_DOMAIN=...
EXPO_PUBLIC_FIREBASE_PROJECT_ID=...
EXPO_PUBLIC_FIREBASE_STORAGE_BUCKET=...
EXPO_PUBLIC_FIREBASE_APP_ID=...

These do not belong in the app bundle: Firebase Admin SDK private keys, service account JSON, RevenueCat webhooks secrets, OpenAI API keys, SMTP credentials, and GitHub tokens.

2. Create EAS environments

EAS has built-in development, preview, and production environments. Create variables with the same names in each environment, then change only the values.

eas env:create --environment development --name EXPO_PUBLIC_FIREBASE_PROJECT_ID --value myapp-dev --visibility plaintext
eas env:create --environment preview --name EXPO_PUBLIC_FIREBASE_PROJECT_ID --value myapp-staging --visibility plaintext
eas env:create --environment production --name EXPO_PUBLIC_FIREBASE_PROJECT_ID --value myapp-prod --visibility plaintext

Use plaintext for public client config, sensitive for values that can be viewed by trusted team members but should be masked in logs, and secret for values only EAS jobs should read.

3. Connect environments to eas.json

Build profiles should say which EAS environment they use. That makes the build command short and reduces mistakes.

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "environment": "development"
    },
    "preview": {
      "distribution": "internal",
      "environment": "preview"
    },
    "production": {
      "autoIncrement": true,
      "environment": "production"
    }
  }
}

Now eas build --profile production --platform all receives production variables without needing a committed .env.production file.

4. Read variables in Firebase setup

Create a small config guard so a missing environment variable fails loudly.

function required(name: string) {
  const value = process.env[name];
  if (!value) {
    throw new Error(`Missing environment variable: ${name}`);
  }
  return value;
}

export const firebaseConfig = {
  apiKey: required("EXPO_PUBLIC_FIREBASE_API_KEY"),
  authDomain: required("EXPO_PUBLIC_FIREBASE_AUTH_DOMAIN"),
  projectId: required("EXPO_PUBLIC_FIREBASE_PROJECT_ID"),
  storageBucket: required("EXPO_PUBLIC_FIREBASE_STORAGE_BUCKET"),
  appId: required("EXPO_PUBLIC_FIREBASE_APP_ID"),
};

This turns a blank production build into a build-time or startup error you can fix quickly, instead of a vague "Firebase App named default already exists" or "project not found" report from a tester.

5. Pull env vars for local debugging

When a cloud build behaves differently from local development, pull the same environment locally.

eas env:pull --environment preview
npx expo start --clear

Do not commit the pulled .env.local. Treat it as a local mirror of the selected EAS environment.

6. Use secrets only for build-time needs

A good use for an EAS secret is an NPM_TOKEN needed to install a private package during the build. A bad use is EXPO_PUBLIC_OPENAI_API_KEY; the public prefix means the value ends up in the app.

Secret does not mean hidden from users

If your JavaScript imports a value and bundles it into the app, users can inspect it. Put privileged operations behind Cloud Functions or another backend.

Production checklist

Use separate Firebase projects for development, preview, and production when data writes matter.
Map every EAS build profile to an explicit environment.
Keep .env* files out of git unless they contain harmless examples only.
Audit variables before the first production build.
Put admin actions behind Cloud Functions, not in app code.

Sources

EAS environment variables | Expo environment variables | Firebase config object