.env File v mobilním vývoji: co to je, účel a princip fungování

Co je .env File a k čemu slouží

.env File je konfigurační soubor, ve kterém jsou uloženy proměnné prostředí v jednoduchém textovém formátu KEY=VALUE. Každý řádek obsahuje jednu proměnnou: název klíče a jeho hodnotu oddělené znakem rovnosti.

Soubory .env řeší zásadní problém moderního vývoje: různá prostředí (lokální, testovací, produkční) vyžadují zcela odlišná nastavení. URL API serveru na lokálním počítači je http://localhost:8080, na produkčním serveru — https://api.production.com. Pokud jsou tyto hodnoty pevně vloženy přímo do kódu aplikace, každé sestavení pro jiné prostředí vyžaduje změnu zdrojového kódu.

Praxe ukládání konfigurace mimo hlavní kód aplikace byla standardizována v manifestu The Twelve-Factor App (2011), který označil proměnné prostředí jako jediný správný způsob konfigurace aplikace. Podle průzkumu JetBrains Developer Ecosystem (2024) používá více než 67% mobilních vývojářů soubory .env ve svých projektech.

Pro mobilní vývoj poskytuje .env další výhodu: hodnoty se dosazují ve fázi sestavení přes Gradle (Android) nebo xcconfig (iOS), což umožňuje vytvářet samostatná sestavení pro vývoj, staging a produkci bez změny zdrojového kódu.

.env je obzvláště užitečný při týmové práci: každý vývojář si vytvoří svůj vlastní lokální .env s nastavením pro své prostředí (cesta k lokální databázi, debug API klíče) a společná nastavení jsou zaznamenána v .env.example v repozitáři. Tím se eliminuje situace, kdy se po git pull vývojáři rozbije sestavení kvůli chybějící proměnné prostředí, o které nevěděl. Nový člen týmu jednoduše zkopíruje .env.example do .env a vyplní své lokální hodnoty.

Syntaxe a struktura .env File

Formát .env je maximálně jednoduchý: každý řádek je jedna proměnná ve tvaru KEY=VALUE. Mezery kolem znaku rovnosti jsou obvykle ignorovány, ale ve většině knihoven jsou považovány za součást hodnoty, proto je lepší se jim vyhnout.

Základní pravidla zápisu

Komentáře začínají znakem # — celý řádek za ním je ignorován. Prázdné řádky jsou také přeskočeny. Pokud hodnota obsahuje mezery, uzavírá se do dvojitých nebo jednoduchých uvozovek.

# Hlavní nastavení prostředí
APP_NAME=MyMobileApp
APP_ENV=development

# API konfigurace
API_BASE_URL=http://localhost:3000/api
API_TIMEOUT=30000

# Citlivá data
DB_PASSWORD=secret_password_123
JWT_SECRET=your_jwt_secret_key

Typy hodnot a escapování

Všechny proměnné v .env jsou řetězce, ale knihovny pro načítání je mohou převést na požadovaný typ. Pro escapování speciálních znaků se používají zpětná lomítka a uvozovky. Pokud hodnota obsahuje znak # jako součást textu, je třeba jej escapovat jako \#.

• Řetězce — bez uvozovek nebo v uvozovkách: KEY=value nebo KEY="value with spaces"
• Čísla — zapisují se bez uvozovek: PORT=8080
• Logické hodnoty — řetězce true/false: DEBUG=true
• Víceřádkové — zpětné lomítko na konci řádku: KEY=line1\
line2
• Substituce — v některých analyzátorech: DB_URL=${DB_HOST}:${DB_PORT}

Při načítání .env mohou knihovny provádět interpolaci proměnných — dosazovat hodnoty jednoho klíče do druhého. Například proměnná DATABASE_URL=postgres://${DB_USER}:${DB_PASS}@localhost/db rozbalí DB_USER a DB_PASS ze stejného souboru.

Integrace .env File do mobilních projektů

Způsob připojení .env závisí na platformě. Android používá Gradle pluginy, iOS — konfigurační soubory xcconfig a multiplatformní řešení jako Flutter — specializované knihovny.

Android a Gradle: nastavení BuildConfig

V Androidu se .env načítá pomocí pluginu gradle-dotenv. Plugin čte .env z kořene projektu a přidává hodnoty do BuildConfig, poté jsou dostupné v kódu Kotlin nebo Java přes vygenerovaná pole.

// build.gradle.kts (app level)
plugins {
    id("co.uzzu.dotenv") version "4.0.0"
}

android {
    buildFeatures {
        buildConfig = true
    }
}

kotlin {
    // Přístup v kódu: BuildConfig.API_BASE_URL
    buildConfigField("String", "API_BASE_URL",
        "\"" + dotenv.get("API_BASE_URL") + "\"")
}

iOS a Xcode: připojení Config

V iOS se proměnné prostředí obvykle konfigurují přes xcconfig soubory. Pro načítání .env ve Swiftu se používá knihovna DotEnv nebo vestavěný mechanismus Info.plist s vlastními klíči.

// Načtení .env ve Swift projektu
import DotEnv

struct AppConfig {
    static func load() {
        let env = DotEnv(Bundle.main)
        env.load()

        let apiURL = ProcessInfo.processInfo
            .environment["API_BASE_URL"] ??
            "https://default.api.com"
    }
}

Flutter a Dart: knihovna flutter_dotenv

Pro Flutter existuje balíček flutter_dotenv, který načítá proměnné z .env během inicializace aplikace. Soubor .env se umístí do kořene projektu a proměnné jsou dostupné přes třídu dotenv.

// pubspec.yaml
dependencies:
  flutter_dotenv: ^5.1

// main.dart — načtení při spuštění
import 'package:flutter_dotenv/flutter_dotenv.dart';

void main() async {
  await dotenv.load(fileName: '.env');
  var apiUrl = dotenv.get('API_BASE_URL');
  runApp(MyApp(baseUrl: apiUrl));
}

Všechny tři přístupy spojuje společný princip: .env se načítá ve fázi sestavení nebo při spuštění aplikace, hodnoty se ukládají do mezipaměti a používají se v kódu přes vygenerované konstanty. Tím se zabrání pronikání citlivých dat do repozitáře.

Pro React Native se používá balíček react-native-config, který ve fázi sestavení automaticky generuje třídu BuildConfig pro Android a konstanty v Info.plist pro iOS z jednoho .env souboru v kořenu projektu. To je zvláště výhodné pro startupy používající Expo nebo bare workflow: stačí jeden .env na kořenové úrovni a všechny platformy obdrží stejné proměnné prostředí bez duplikování konfigurací.

Bezpečnost a nejlepší postupy .env File

Navzdory všem výhodám není .env plnohodnotným řešením pro ukládání tajemství v produkčním prostředí. Poskytuje základní úroveň ochrany, ale při nesprávném použití může vést k úniku důvěrných dat.

Ochrana pomocí .gitignore

Nejdůležitější pravidlo — .env by nikdy neměl skončit v systému správy verzí. Soubor se přidá do .gitignore ihned po vytvoření a do repozitáře se commitue pouze vzorový soubor .env.example s prázdnými nebo fiktivními hodnotami.

# .env.example — commitováno do repozitáře
APP_NAME=
APP_ENV=development
API_BASE_URL=http://localhost:3000
API_TIMEOUT=30000
# DB_PASSWORD — neuvádějte ani v příkladu!
# JWT_SECRET — neuvádějte ani v příkladu!

# .gitignore
# Dotenv soubory
.env
.env*.local

Alternativy pro produkční prostředí

Pro produkční projekty se doporučuje používat profesionální řešení pro správu tajemství. .env v produkci je povolen pouze tehdy, pokud je soubor umístěn mimo document-root serveru a má přísná přístupová práva.

• AWS Secrets Manager — cloudové úložiště tajemství s rotací klíčů a auditem přístupu
• Google Secret Manager — služba Google Cloud pro ukládání API klíčů a hesel
• HashiCorp Vault — nástroj s dynamickými tajemstvími a šifrováním na straně serveru
• Firebase Remote Config — cloudová konfigurace s A/B testováním pro mobilní aplikace
• GitLab CI/CD Variables — vestavěné úložiště tajemství pro pipeline sestavení

Podle Snyk State of Open Source Security (2024) byl únik .env souborů přes repozitáře příčinou více než 12% všech incidentů s odhalením API klíčů mezi dotazovanými společnostmi. Použití samostatného správce tajemství umožňuje snížit toto riziko na nulu.

Dodatečná ochrana se dosahuje zavedením pre-commit hooků pomocí nástrojů jako husky a lint-staged, které kontrolují, zda vývojář náhodně nepřidal .env do commitu. Nástroje jako git-secrets (AWS) a talisman skenují každý commit na vzory API klíčů, tokenů a hesel a blokují commit při detekci. Pro CI pipeline se doporučuje přidat kontrolu detect-secrets — automatický skener, který nepustí .env soubor do repozitáře ani při chybě vývojáře.