Cum gestionezi corect secrets în Expo și EAS fără să-ți spargi aplicația în producție

Ștefan Iliescu · 2026-07-24T13:09:35.457Z

Ghid practic despre .env, EXPO_PUBLIC_ și EAS Secrets. Cum previi scurgerea cheilor de API și ce încurcături apar când treci la producție.

Postat 24 iul. 2026

typescript

import { ExpoConfig, ConfigContext } from 'expo/config';

export default ({ config }: ConfigContext): ExpoConfig => {
  const IS_DEV = process.env.APP_VARIANT === 'development';

  return {
    ...config,
    name: IS_DEV ? 'App (Dev)' : 'App Clean',
    slug: 'app-clean',
    extra: {
      // Preluat din EAS Secrets la build sau din mediul local
      sentryDsn: process.env.SENTRY_DSN,
      apiUrl: process.env.EXPO_PUBLIC_API_URL,
      eas: {
        projectId: 'your-project-id-here'
      }
    }
  };
};

Am văzut prea multe aplicații de Expo pe GitHub cu chei de Firebase, Stripe sau Sentry trântite direct în repo. Dacă folosești EAS Build și nu ești atent la diferența dintre environment variables de build time și runtime, e doar o chestiune de timp până când trimiți webhook-uri de dev în baza de date de producție. Hai să lămurim exact cum structurăm secretele și variabilele de mediu fără să ne complicăm viața.

Marea capcană: EXPO_PUBLIC_ nu înseamnă secret

De la SDK 49 încoace, Expo folosește prefixul EXPO_PUBLIC_ pentru a expune variabilele în codul de client (JavaScript bundle).

Dacă scrii EXPO_PUBLIC_API_URL=https://api.myapp.com în .env, valoarea aia ajunge direct în bundle-ul final. Oricine decompilează APK-ul sau extrage bundle-ul de JS o poate citi în 10 secunde.

Caz real: la un proiect cu 12k utilizatori activi, un coleg a pus din greșeală un API token secret cu prefixul EXPO_PUBLIC_, crezând că Expo îl ascunde automat la build. Token-ul respectiv avea acces de scriere în SendGrid. Ne-am prins abia după ce am văzut utilizare suspectă în dashboard-ul de emailuri.

Regulă simplă:

Chei publice (Supabase anon key, Firebase API key, URL-uri de backend): folosești EXPO_PUBLIC_ în .env.development și .env.production.
Chei private (Sentry Auth Token, Apple Team ID, AWS Secret Key): NICIODATĂ cu EXPO_PUBLIC_ și NICIODATĂ comise în repo.

Cum gestionezi secretele reale cu EAS Secrets

Pentru chestiile care trebuie să rămână secrete și sunt folosite doar în timpul procesului de build, soluția curată este EAS Secrets. Le configurezi o singură dată din CLI sau din dashboard-ul Expo, iar ele sunt injectate în runner-ul de build din cloud.

EAS le păstrează criptate și nu le expune în logurile publice de build. Nu mai trebuie să ai fișiere .env.production locale pline de token-uri sensibile pe laptopurile tuturor din echipă.

.env.development vs .env.production cu app.config.ts

Pentru variabilele care schimbă comportamentul aplicației între medii (ex: API endpoints diferite), cea mai elegantă abordare este să folosești un app.config.ts dinamic. În loc să te bazezi pe magia că Expo încarcă fișierul corect, citești explicit mediu curent și trimiți valorile în câmpul extra.

Trade-off-ul de care nu-ți spune nimeni

EAS Secrets e genial dacă faci toate build-urile în cloud-ul Expo. Merge brici, e securizat și nu-ți băți capul.

Dar iată unde apare problema: dacă vrei să faci build-uri locale (eas build --local) ca să economisești creditele pe EAS sau să faci debug rapid pe un Mac, EAS Secrets nu sunt disponibile. În scenariul ăsta, trebuie să-ți creezi manual un fișier .env.local securizat separat, altfel build-ul local va eșua tăcut sau va folosi valori de fallback greșite.

Voi cum gestionați diferențierea de secrets când aveți build-uri locale și pipeline-uri de CI/CD pe Expo?