Jak porovnat .env soubory mezi prostředími
Deployoval jsem a aplikace spadla. Důvod? Chyběla env proměnná co byla na dev, ale ne na produkci. Od té doby před každým deployem porovnávám .env soubory.
Co je .env soubor
Textový soubor s proměnnými prostředí - databáze, API klíče, nastavení aplikace. Každé prostředí (dev, staging, produkce) má trochu jiný.
Typická struktura .env souboru:
# Databáze
DATABASE_URL=postgresql://user:password@localhost:5432/myapp
DATABASE_POOL_SIZE=10
# API klíče
STRIPE_SECRET_KEY=sk_test_xxxxxxxxxxxxx
SENDGRID_API_KEY=SG.xxxxxxxxxxxxxxxx
# Aplikační nastavení
APP_ENV=development
APP_DEBUG=true
APP_URL=http://localhost:3000
# Redis cache
REDIS_URL=redis://localhost:6379
Proč potřebujete různá prostředí?
Vývojové prostředí (development):
- Lokální databáze
- Testovací API klíče
- Debug mód zapnutý
- Volnější bezpečnostní pravidla
Testovací prostředí (staging):
- Kopie produkční databáze (anonymizovaná)
- Sandbox API klíče
- Podobná konfigurace jako produkce
- Přístup pro testery
Produkční prostředí (production):
- Ostrá databáze
- Skutečné API klíče
- Debug vypnutý
- Maximální bezpečnost
Proč je porovnání .env souborů kritické?
1. Chybějící proměnné způsobují pády aplikace
Nejčastější problém: Vývojář přidá novou proměnnou do lokálního .env, ale zapomene ji přidat na produkci. Aplikace pak spadne s chybou "undefined environment variable".
Příklad reálné situace:
# .env.development (lokální)
DATABASE_URL=postgresql://localhost/myapp
REDIS_URL=redis://localhost:6379
NEW_FEATURE_API_KEY=test_key_12345 # Nově přidáno
# .env.production (produkce)
DATABASE_URL=postgresql://prod-server/myapp
REDIS_URL=redis://prod-redis:6379
# NEW_FEATURE_API_KEY chybí! → Aplikace spadne
2. Bezpečnostní rizika
Testovací klíče na produkci mohou způsobit:
- Úniky citlivých dat
- Finanční ztráty (např. špatný Stripe klíč)
- Bezpečnostní incidenty
3. Různé hodnoty způsobují nekonzistentní chování
Když se hodnoty proměnných liší, aplikace se chová jinak v různých prostředích:
# .env.staging
MAX_UPLOAD_SIZE=10MB
SESSION_TIMEOUT=3600
# .env.production
MAX_UPLOAD_SIZE=5MB # Přísnější limit
SESSION_TIMEOUT=1800 # Kratší timeout
Jak efektivně porovnat .env soubory
Metoda 1: Online nástroj PorovnejText.cz
Nejrychlejší způsob pro okamžité porovnání:
- Otevřete PorovnejText.cz
- Vložte obsah prvního .env souboru do levého pole
- Vložte obsah druhého .env souboru do pravého pole
- Klikněte na "Porovnat"
Výhody:
- ✅ Okamžitý výsledek
- ✅ Barevné zvýraznění rozdílů
- ✅ Žádná instalace
- ✅ 100% soukromí – soubory zůstávají v prohlížeči
Tip: Před porovnáním seřaďte klíče abecedně pro lepší přehlednost:
sort .env.development > .env.dev.sorted
sort .env.production > .env.prod.sorted
Metoda 2: Příkazová řádka (diff)
Pro rychlé porovnání v terminálu:
# Základní diff
diff .env.development .env.production
# Side-by-side zobrazení
diff -y .env.development .env.production
# Pouze názvy proměnných (bez hodnot)
diff <(cut -d= -f1 .env.development | sort) <(cut -d= -f1 .env.production | sort)
Metoda 3: Skript pro kontrolu klíčů
Vytvoření vlastního skriptu pro kontrolu chybějících proměnných:
#!/bin/bash
# check-env.sh - Kontrola konzistence .env souborů
ENV_DEV=".env.development"
ENV_PROD=".env.production"
echo "=== Proměnné pouze v DEVELOPMENT ==="
comm -23 <(cut -d= -f1 "$ENV_DEV" | grep -v "^#" | sort) \
<(cut -d= -f1 "$ENV_PROD" | grep -v "^#" | sort)
echo ""
echo "=== Proměnné pouze v PRODUCTION ==="
comm -13 <(cut -d= -f1 "$ENV_DEV" | grep -v "^#" | sort) \
<(cut -d= -f1 "$ENV_PROD" | grep -v "^#" | sort)
Metoda 4: VS Code rozšíření
Pro vývojáře používající VS Code:
- Otevřete oba soubory
- Pravý klik → "Select for Compare"
- Pravý klik na druhý soubor → "Compare with Selected"
Best practices pro správu .env souborů
1. Používejte .env.example jako šablonu
Vytvořte soubor .env.example s prázdnými hodnotami a commitněte ho do repozitáře:
# .env.example (commitovaný do Gitu)
DATABASE_URL=
REDIS_URL=
STRIPE_SECRET_KEY=
APP_ENV=
APP_DEBUG=
Výhody:
- Dokumentace všech potřebných proměnných
- Nový vývojář ví, co nastavit
- Lze automaticky kontrolovat proti skutečným .env
2. Automatická kontrola v CI/CD
Přidejte do CI pipeline kontrolu konzistence:
# .github/workflows/check-env.yml
name: Check Environment Variables
on: [push, pull_request]
jobs:
check-env:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check .env.example completeness
run: |
# Extrahuj klíče z .env.example
EXAMPLE_KEYS=$(cut -d= -f1 .env.example | grep -v "^#" | sort)
# Zkontroluj, že všechny klíče jsou dokumentované
if [ -f ".env.production.template" ]; then
PROD_KEYS=$(cut -d= -f1 .env.production.template | grep -v "^#" | sort)
MISSING=$(comm -13 <(echo "$EXAMPLE_KEYS") <(echo "$PROD_KEYS"))
if [ -n "$MISSING" ]; then
echo "Chybějící proměnné v .env.example:"
echo "$MISSING"
exit 1
fi
fi
3. Validace při startu aplikace
Přidejte validaci proměnných prostředí do aplikace:
// config/env.ts
const requiredEnvVars = [
'DATABASE_URL',
'REDIS_URL',
'APP_ENV',
'SESSION_SECRET'
];
export function validateEnv(): void {
const missing = requiredEnvVars.filter(
(key) => !process.env[key]
);
if (missing.length > 0) {
throw new Error(
`Chybějící proměnné prostředí: ${missing.join(', ')}`
);
}
}
4. Používejte nástroje pro správu secrets
Pro větší projekty zvažte:
dotenv-vault – Šifrované .env soubory s verzováním HashiCorp Vault – Enterprise řešení pro správu secrets AWS Secrets Manager – Cloud-native řešení pro AWS Azure Key Vault – Microsoft cloud řešení
Častá úskalí a jak se jim vyhnout
Úskalí 1: Commitování .env do Gitu
Problém: Skutečný .env soubor se dostal do repozitáře.
Řešení:
# .gitignore
.env
.env.local
.env.*.local
.env.production
.env.staging
# Povoleno
.env.example
.env.template
Pokud už je soubor commitovaný:
git rm --cached .env
git commit -m "Remove .env from tracking"
# Nezapomeňte změnit všechny kompromitované klíče!
Úskalí 2: Různé formáty hodnot
Různá prostředí mohou mít různé formáty:
# Development
DATABASE_URL=postgresql://localhost/myapp
# Production (s parametry)
DATABASE_URL=postgresql://user:pass@host/db?sslmode=require&pool=10
Tip: Při porovnávání se zaměřte na strukturu URL, ne přesnou shodu.
Úskalí 3: Komentáře a prázdné řádky
Různé formátování může zmást diff nástroje:
# File 1
DATABASE_URL=...
# Komentář
REDIS_URL=...
# File 2
DATABASE_URL=...
REDIS_URL=...
# Komentář na jiném místě
Řešení: Před porovnáním odstraňte komentáře:
grep -v "^#" .env | grep -v "^$" | sort
Úskalí 4: Citlivá data v porovnání
Při sdílení výsledků porovnání (např. v pull requestu):
NIKDY neposílejte:
- API klíče
- Hesla
- Connection strings s credentials
Bezpečná alternativa:
# Porovnejte pouze názvy proměnných
diff <(cut -d= -f1 .env.dev | sort) <(cut -d= -f1 .env.prod | sort)
Automatizace: Skript pro komplexní kontrolu
Zde je kompletní skript pro kontrolu .env souborů:
#!/bin/bash
# env-diff.sh - Komplexní kontrola .env souborů
set -e
# Barvy pro výstup
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color
# Výchozí soubory
FILE1="${1:-.env.development}"
FILE2="${2:-.env.production}"
EXAMPLE="${3:-.env.example}"
echo "================================================"
echo "Porovnání: $FILE1 vs $FILE2"
echo "================================================"
# Funkce pro extrakci klíčů
get_keys() {
grep -v "^#" "$1" 2>/dev/null | grep -v "^$" | cut -d= -f1 | sort
}
KEYS1=$(get_keys "$FILE1")
KEYS2=$(get_keys "$FILE2")
# 1. Klíče pouze v prvním souboru
echo -e "\n${YELLOW}[1] Proměnné pouze v $FILE1:${NC}"
ONLY_IN_1=$(comm -23 <(echo "$KEYS1") <(echo "$KEYS2"))
if [ -z "$ONLY_IN_1" ]; then
echo -e "${GREEN} Žádné${NC}"
else
echo -e "${RED}$ONLY_IN_1${NC}" | sed 's/^/ /'
fi
# 2. Klíče pouze v druhém souboru
echo -e "\n${YELLOW}[2] Proměnné pouze v $FILE2:${NC}"
ONLY_IN_2=$(comm -13 <(echo "$KEYS1") <(echo "$KEYS2"))
if [ -z "$ONLY_IN_2" ]; then
echo -e "${GREEN} Žádné${NC}"
else
echo -e "${RED}$ONLY_IN_2${NC}" | sed 's/^/ /'
fi
# 3. Kontrola proti .env.example
if [ -f "$EXAMPLE" ]; then
echo -e "\n${YELLOW}[3] Kontrola proti $EXAMPLE:${NC}"
EXAMPLE_KEYS=$(get_keys "$EXAMPLE")
MISSING_FROM_1=$(comm -23 <(echo "$EXAMPLE_KEYS") <(echo "$KEYS1"))
MISSING_FROM_2=$(comm -23 <(echo "$EXAMPLE_KEYS") <(echo "$KEYS2"))
if [ -n "$MISSING_FROM_1" ]; then
echo -e "${RED} Chybí v $FILE1:${NC}"
echo "$MISSING_FROM_1" | sed 's/^/ /'
fi
if [ -n "$MISSING_FROM_2" ]; then
echo -e "${RED} Chybí v $FILE2:${NC}"
echo "$MISSING_FROM_2" | sed 's/^/ /'
fi
if [ -z "$MISSING_FROM_1" ] && [ -z "$MISSING_FROM_2" ]; then
echo -e "${GREEN} Všechny proměnné jsou přítomny${NC}"
fi
fi
# 4. Souhrn
echo -e "\n================================================"
TOTAL_1=$(echo "$KEYS1" | wc -l | tr -d ' ')
TOTAL_2=$(echo "$KEYS2" | wc -l | tr -d ' ')
echo "Celkem proměnných: $FILE1=$TOTAL_1, $FILE2=$TOTAL_2"
echo "================================================"
Integrace do vývojového workflow
Pre-commit hook
Přidejte automatickou kontrolu před každým commitem:
#!/bin/bash
# .git/hooks/pre-commit
# Kontrola, že .env není commitován
if git diff --cached --name-only | grep -q "^\.env$"; then
echo "CHYBA: Pokoušíte se commitnout .env soubor!"
echo "Odstraňte ho ze stage: git reset HEAD .env"
exit 1
fi
# Kontrola, že .env.example je aktuální
if [ -f ".env.example" ] && [ -f ".env" ]; then
EXAMPLE_KEYS=$(cut -d= -f1 .env.example | grep -v "^#" | sort)
ENV_KEYS=$(cut -d= -f1 .env | grep -v "^#" | sort)
NEW_KEYS=$(comm -13 <(echo "$EXAMPLE_KEYS") <(echo "$ENV_KEYS"))
if [ -n "$NEW_KEYS" ]; then
echo "VAROVÁNÍ: Tyto proměnné nejsou v .env.example:"
echo "$NEW_KEYS"
echo "Přidejte je do .env.example"
fi
fi
Docker Compose validace
Pro projekty s Dockerem:
# docker-compose.yml
services:
app:
build: .
env_file:
- .env
environment:
# Vynucené proměnné - musí být definovány
- DATABASE_URL
- REDIS_URL
- APP_ENV
Závěr
Správné porovnávání .env souborů mezi prostředími je základem stabilního a bezpečného vývoje. Klíčové body:
1. Pravidelně porovnávejte – Ideálně automaticky v CI/CD pipeline
2. Používejte .env.example – Jako dokumentaci a referenci pro všechny proměnné
3. Automatizujte kontroly – Pre-commit hooky a CI pipeline zabrání chybám
4. Chraňte citlivá data – Nikdy nesdílejte skutečné hodnoty, pouze názvy proměnných
5. Validujte při startu – Aplikace by měla selhat rychle, pokud chybí kritická konfigurace
Potřebujete rychle porovnat .env soubory? Vyzkoušejte PorovnejText.cz – stačí vložit obsah obou souborů a okamžitě uvidíte rozdíly. Vše probíhá ve vašem prohlížeči, vaše konfigurace zůstává v bezpečí.
Vyzkoušejte PorovnejText.cz zdarma
Nejrychlejší český nástroj pro porovnání textů. Vše probíhá ve vašem prohlížeči, žádná registrace není potřeba.
Porovnat texty nyní →Související články
Jak kontroluju config soubory před deployem
Jedna špatná změna v YAML a máte outage. Tady je jak porovnávám konfigurace mezi prostředími.
XML konfiguráky - jak je porovnat bez bolesti hlavy
Praktické tipy na porovnávání XML souborů. Od Spring configu přes Maven POM po .NET app.config - co funguje a na co si dát pozor.
Porovnávání server configů - jak to dělám já
Praktický DevOps návod na porovnávání konfigurací. Od nginx přes Kubernetes po automatizaci v CI/CD.